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THE  MOBILE  INTEGRATED 
TACTICAL  TERMINAL  (MITT) 

/\  CiLs'c  SlLidv  in  Rapid  Pcwdni'ninni 


Major  Lillian  A.  Pfluke,  USA 


Te  first  Mobile  Integrated  Tactical 
Terminal  (MITT),  latest  de¬ 
velopment  effort  by  the  Army 
Space  Program  Office  (ASPO), 
was  recently  fielded  to  the  319th  Mili¬ 
tary  Intelligence  Battalion  at 
Fort  Bragg,  N.C.,  only  36  months 
after  Concept  Studies  Approval 
(Milestone  0). 

This  rapid  development  was  pos¬ 
sible  because  we  used  concurrency 
throughout  the  acquisition  process: 
we  did  more  than  one  thing  at  a  time, 
and  we  didn’t  wait  to  complete  ad¬ 
ministrative  requirements  before  pro¬ 
ceeding  with  other  phases  of  the  pro¬ 
gram. 

Also,  we  used  an  innovative  ap¬ 
proach  to  transition  this  program  from 
a  highly  classified  contracting  and 
development  process  to  a  standard 
program  development.  This  allowed 
the  program  to  take  advantage  of  both 
the  highly  technical,  rapid  and  unique 
development  process  possible  in  the 
classified  world  and  the  standardized, 
supportable  and  reproducible  devel¬ 
opment  process  possible  in  the  acqui¬ 
sition  world. 


Major  Pfluke  is  Systems  Coordina¬ 
tor  in  the  Department  of  the  Army 
Research,  Development  and  Acquisi¬ 
tion  (SARDA)  for  Patriot  Missiles,  the 
Pentagon.  She  was  the  MITT  program 
manager  from  March  1990  through 
June  1 993.  She  is  a  PMC  94-2  student. 


.Mt, 


Major  Pfluke  describes  the  MITT  power  system  to  BG  John  E.  Longhouser,  USA,  then  Assis 
lant  Deputy  for  Systems  Management,  Office  of  the  Assistant  Secretary'  of  the  Army  (Research, 
Development  and  Acquisition). 


While  this  is  a  unique  program 
with  unique  circumstances,  some  of 
the  procedures  used  and  lessons 
learned  are  relevant  to  the  acquisi- 


shrinking  budgets  and  rapidly  mov¬ 
ing  technology,  all  program  managers 
(PMs)  must  strive  continuously  to 
shorten  the  acquisition  cycle;  some  of 


tion  community  at  large.  In  an  era  of  the  experiences  of  the  MITT  program 
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may  apply  to  this  need.  This  article 
describes  how  this  successful  acqui¬ 
sition  took  place  so  rapidly. 

Background 

The  ASPO  director  is  the  PM  of  the 
Army  “Tactical  Exploitation  of  Na¬ 
tional  Capabilities”  (TENCAP)  Pro¬ 
gram.  The  ASPO  is  not  in  the  Army 
Program  Executive  Office  (PEO)  struc¬ 
ture  under  the  Assistant  Secretary  of 
the  Army  (Research,  Development 
and  Acquisition)  but  is  a  field  operat¬ 
ing  agency  of  the  Department  of  the 


Army  Deputy  Chief  of  Staff  for  Opera¬ 
tions  and  Plans.  As  such,  .\SPO  ex¬ 
ecutes  the  TENCAP  program  as  ap¬ 
proved  by  the  TENCAP  general 
officers  steering  group,  which  is  co¬ 
chaired  by  the  Army  Deputy  Chief  of 
Staff  for  Operations  and  Assistant 


Secretary  of  the  Army  (Research,  De¬ 
velopment  and  Acquisition).  The 
ASPO  is  the  Army  focal  point  for  tech¬ 
nical,  fiscal  and  operational  interac¬ 
tions  with  the  national  space  commu¬ 
nity:  and,  as  such,  develops,  tests, 
fields  and  sustains  tactical  systems 
for  national  and  theater  intelligence 
products. 

In  1978,  the  ASPO  fielded  its  first 
signals  intelligence  system,  the  Elec¬ 
tronic  Processing  and  Dissemination 
System,  its  first  intelligence  systems. 
Since  then,  24  other  TENCAP  sys- 
E  terns  of  various  sizes,  missions  and 
I  complexity  have  been  developed, 
Q  fielded  and  are  operating  throughout 
e-the  world  at  Army  divisions,  corps 
E  and  echelons  above  corps.  The  sys- 
-g  terns  are  supported  by  contractor  field- 
>,  service  representatives  permanently 
I  on  site  with  each  piece  of  equipment. 
CO  The  computers  in  the  original  TENCAP 
a  systems  are  dated,  the  software  is 
Z  expensive  to  maintain,  and  the  sys- 
>.  terns  are  operating  at  their  maximum 
^  level  with  no  growth  potential. 

O 

O 

1  The  ASPO  coordinates  with  key 
OT  personnel  in  TENCAP  cells  at  every 
^  command  where  TENCAP  equipment 

is  used  to  expedite  actions  appropri- 
Q  ate  to  that  command.  This  allows  the 

2  ASPO  to  obtain  a  materiel  require- 
ment  approved  by  the  TENCAP  Gen¬ 
eral  Officers  Steering  Group  while  for¬ 
mal  documentation  is  still  in  the 
Training  and  Doctrine  Command 
(TRADOC)  pipeline.  Thus,  ASPO  tra¬ 
ditionally  strives  for  “the  80-percent 
solution”  during  development,  and 
relies  on  close  contact  with  the  user  in 
the  field  and  extensive  preplanned 
product  improvements  to  refine  sys¬ 
tem  capabilities.  This  allows  the  PM 
to  write  rather  general  specifications 
for  the  contractor,  and  then  work 
closely  with  the  contractor  and  the 
user  during  system  development. 

Pre-Milestone  0  Activities 

From  1987-89,  16  different  Mis¬ 
sion  Need  Statements  (MNSs)  were 
generated  at  various  divisions  and 
schools  expressing  a  requirement  for 


TENCAP  capability  at  lower  levels  on 
the  battlefield.  During  the  Gulf  War, 
all  five  Tactical  High  Mobility  Termi¬ 
nals  were  deployed,  and  three  were 
sent  forward  with  divisions  for  the 
first  time.  Tactical  High  Mobility  Ter¬ 
minals  are  highly  mobile  systems  that 
allow  a  single  operator/analyst  to  re¬ 
ceive.  analyze,  archive  and  dissemi¬ 
nate  signals  intelligence  and  imagery 
intelligence  products.  Intended  for  use 
at  the  Corps  Forward  Command  Post, 
these  systems  proved  extremely  suc¬ 
cessful  at  the  division  level,  validat¬ 
ing  in  wartime  experience  the  need 
for  such  a  system  in  divisions. 

Even  before  the  Gulf  War,  it  was 
clear  that  a  material  solution  was  in¬ 
dicated  to  get  more  TENCAP  capabil¬ 
ity  on  the  battlefield.  The  Tactical 
High  Mobility  Terminal  was  the  best 
system  for  use  at  division  level,  but 
expensive  to  reproduce  because  the 
government  did  not  own  the  technical 
data  package  (the  five  systems  in  ex¬ 
istence  were  prototypes  and  never 
intended  for  a  more  extensive  field¬ 
ing).  Also,  several  of  the  systems  were 
mounted  on  five  trucks  and  the  MNSs 
called  for  a  smaller  system.  Finally, 
the  systems  were  already  pushing  the 
limits  of  their  intended  processing 
capacity,  and  it  seemed  short-sighted 
to  reproduce  a  system  headed  for 
obsolescence. 

Thus,  based  on  informally  stated 
requirements  from  the  field  (a  formal 
consolidated  MNS  was  never  written) 
and  the  clear  need  for  a  material  solu¬ 
tion,  the  TENCAP  General  Officers 
Steering  Group  directed  on  6  July  1990 
that  ASPO  pursue  the  prototype  de¬ 
velopment  of  a  smaller  and  updated 
Tactical  High  Mobility  Terminal.  Five 
prototypes  would  be  built  for  test  and 
evaluation.  The  PEO  for  Intelligence 
and  Electronic  Warfare  would  assist 
ASPO  in  documentation  and  devel¬ 
opment  to  ensure  the  technology  used 
was  consistent  with  the  Intelligence 
and  Electronic  Warfare  Systems  open 
systems  architecture.  Milestone  0, 
Concept  Studies  Approval,  was 
achieved. 
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Phase  0:  Concept  Exploration 
and  Definition 

The  purpose  of  concept  explora¬ 
tion  and  definition  is  to  evaluate  the 
feasibility  of  alternative  concepts  and 
determine  the  most  promising  solu¬ 
tions.  Two  separate  evaluations  for 
this  system  were:  the  software  archi¬ 
tecture  and  associated  hardware  suite, 
and  the  vehicle/shelter/trailer  system 
configuration.  The  ASPO  formed  two 
teams  of  experts  to  address  the 
problem. 

The  software/hardware  team  of 
experts  were  from  the  program  office, 
the  contracting  office,  and  the  sup¬ 
porting  Federiil  Contracts  Research 
Center.  Their  study  began  on  8  Au¬ 
gust  1990,  and  included  coordination 
visits  with  16  different  Department  of 
Defense  (DoD)  agencies  engaged  in 
intelligence,  electronic  warfare,  com¬ 
munications  and  computer  technol¬ 
ogy.  Their  final  product  was  a  15 
November  1990  decision  brief,  rec¬ 
ommending  the  hardware  and  soft¬ 
ware  approaches  to  be  pursued  in  the 
newly  designated  MITT. 

Because  of  the  Gulf  War,  the 
TENCAP  General  Officer’s  Steering 
Group  did  not  meet  in  the  December/ 
January  timeframe  to  give  formal  Con¬ 
cept  Demonstration  Approval  (Mile¬ 
stone  1)  for  the  software  effort.  The 
contracting  process  proceeded  with 
an  informal  approval  from  the  co¬ 
chairs  of  the  group.  As  with  all  previ¬ 
ous  contracts  for  other  TENCAP  sig¬ 
nals  intelligence  systems,  cost-plus- 
award-fee  contract  was  awarded  to 
rehost  Tactical  High  Mobility  Termi¬ 
nal  functionality  onto  a  UNIX 
baseline.  (This  meant  the  MITT  could 
execute  all  of  the  functions  of  the 
previous  system  but  could  use  the 
most  modem  computer  technology.) 
Authority  to  proceed  was  granted 
on  1  February  1991,  and  the  con¬ 
tract  was  expected  to  be  a  22-month 
effort. 

As  the  software  contracting  pro¬ 
cess  was  taking  place,  a  second  team 
of  experts  was  formed  to  evaluate 


alternative  concepts  for  the  system. 
When  the  software/hardware  experts 
had  visited  the  Army  Research  Labo¬ 
ratory  in  Adelphi,  Md.,  they  were  so 
impressed  with  the  type  of  work  in 
packaging  VME-based  computer  sys¬ 
tems  in  rugged  tactical  cases  and  ve¬ 
hicles  being  done  there  that  it  was 
decided  that  the  Army  Research  Labo¬ 
ratory  experience  would  be  invalu¬ 
able  to  the  program.  The  Laboratory 
had  extensive  UNIX  expertise  and 
had  written  software  packages  that 
would  pertain  to  the  program.  Four 
engineers  from  the  Laboratory  gained 
the  appropriate  security  clearances  to 
participate  in  the  program  and  began 
work  on  the  system  design. 

The  system  design  team  was  two 
teams  —  the  four  Laboratory  engi¬ 
neers  and  a  complement  of  engineers 
from  the  defense  contractor.  The  con¬ 
tractor  team  was  expert  in  aerospace 
and  satellite  technology  and  had  more 
than  20  years  of  experience  in 
TENCAP  systems.  The  team  had 
people  thoroughly  familiar  with  the 
software  package  and  a  network  of 
field  service  reps  who  dealt  with 
TENCAP  systems  and  TENCAP  mis¬ 
sions  daily,  worldwide.  The  team  was 
accustomed  to  working  with  large 
vans,  however,  in  special  units  with 
highly  trained  soldiers,  and  with  mini¬ 
mal  thought  given  to  supportability  or 
commonality  with  other  Army  sys¬ 
tems  because  of  their  ongoing  main¬ 
tenance  contract.  Additionally,  since 
they  had  enjoyed  a  long-term,  sole- 
source  relationship  with  ASPO,  they 
were  somewhat  expensive. 

The  teams  each  designed  the  sys¬ 
tem  independently.  A  series  of  itera¬ 
tive  design  concept  meetings  were 
then  held  to  take  the  best  ideas  from 
each  design.  Also,  the  teams  had  a 
joint  conference  with  the  PEO  tor  In¬ 
telligence  and  Electronic  Warfare  and 
several  Intelligence  and  Electronic 
VVarfare  PMs  at  Vint  Hill  Farms,  Va., 
to  share  ideas  and  ensure  system  com¬ 
patibility  and  component  commonal¬ 
ity.  The  sessions  fully  utilized  the 
respective  expertise  of  the  teams  to 


The  Mobile  Integrated  Tactical  Terminal  is  a 
hea\y  high-mobility,  multipurpose,  wheeled 
vehicle  (HMM\W)  with  shelter  that  contains 
two  workstations  and  multiple  communica- 

come  up  with  a  concept  which  would 
not  have  been  possible  by  either  team 
alone.  The  PM’s  challenge  was  to 
help  everyone  set  aside  egos  and 
suspicions  and  work  together  (a  chal¬ 
lenge  that  continued  throughout  the 
program). 
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tions  paths.  It  pulls  a  trailer-mounted  15kw 
generator.  A  second  heavy  HMMUV  carries 
the  crew  and  their  cargo. 


After  this  series  of  iterative  system 
design  concept  meetings,  the  final 
product  of  the  system  design  team 
was  a  21  May  1991  decision  brief 
recommending  the  system  configura¬ 
tion.  The  concept  was  aggressive.  The 
design  depended  on  several  key  pieces 


of  equipment  not  yet  available,  in¬ 
cluding  the  heavy  variant  of  the 
HMMWV.  miniaturized  crypto¬ 
graphic  equipment,  the  SUN  SPARC 
2E  card  (the  smaller,  more  rugged 
computer  card  that  would  allow  the 
system  to  use  the  most  recent  work¬ 
stations  available),  and  the  400-amp 
alternator  for  “under  the  hood”  power. 
Successful  completion  of  the  total 
system  depended  on  the  timely  field¬ 
ing  of  these  other  systems.  .Ml  of  this 
equipment  was  late  for  a  variety  of 
reasons  —  the  minicrypto  still  isn’t 
available;  and  the  PM  executed  some 
creative  “workarounds”  to  keep  de¬ 
velopment  on  schedule.  The  result  of 
accepting  this  risk  was  that  when  the 
system  was  fielded,  it  reflected  cur¬ 
rent  technology,  and  was  the  first 
military  system  fielded  with  this  equip¬ 
ment. 

As  work  on  the  MITT  Operational 
Requirements  Document  had  begun 
at  the  Army  Training  and  Doctrine 
Command  and  the  initial  draft  was 
being  staffed,  we  developed  a  revolu¬ 
tionary  acquisition  plan.  The  TENCAP 
signals  intelligence  systems,  to  date, 
had  been  contracted  to  the  same  con¬ 
tractor,  because  of  that  contractor’s 
unique  technical  expertise.  The  sys¬ 
tems  had  been  intended  as  proto¬ 
types  or  low-density  systems  and, 
thus,  were  used  in  the  field 
without  complete  military  specifica¬ 
tion  documentation,  integrated  logis¬ 
tic  support  (ILS)  package,  or  compre¬ 
hensive  manuals.  They  were 
developed  with  minimal  technical  in¬ 
put  from  the  program  office  (because 
of  their  extreme  complexity,  the  pro¬ 
gram  office  often  did  not  have  the 
technical  expertise  to  give  precise 
guidance  and  make  engineering  deci¬ 
sions). 

Since  the  MITT  would  bring 
TENCAP  capability  to  the  division  for 
the  first  time  and  since  the  total  num¬ 
ber  of  MITTs  was  potentially  more 
than  100  systems  (at  one  point  the 
MITT  was  to  be  the  prototype  for  the 
Common  Ground  Station),  this  ap¬ 
proach  would  no  longer  work.  In¬ 


stead,  while  the  contractor  was  build¬ 
ing  the  five  approved  prototypes,  one 
additional  system  would  be  built  at 
the  Army  Research  l.aboratory.  This 
sixth  system  would  allow  the  Army 
Research  Laboratory  to  validate  the 
contractor’s  engineering  drawings  and 
bring  them  up  to  level-three  stan¬ 
dards,  and  to  make  minor  changes  in 
the  system  (which  would  not  affect 
form,  fit  and  function)  to  enhance 
producibility.  Moreover,  the  Army 
would  develop  a  second  source  of 
TENCAP  expertise  to  help  reduce  the 
cost  of  future  systems,  and  the  labo¬ 
ratory  could  produce  an  ILS  package 
for  the  system. 

The  May  1991  TENCAP  General 
Officer’s  Steering  Group  meeting  was, 
in  effect,  a  Concept  Demonstration 
Approval  (Milestone  1)  decision,  al¬ 
though  the  software  contract  was 
signed  three  months  earlier,  and  the 
Operation  Requirements  Document 
was  not  complete.  The  software  and 
hardware  concept  baselines  were  ap¬ 
proved.  The  steering  group  withheld 
judgment  on  the  final  system  configu¬ 
ration  (whether  to  use  a  trailer  or  a 
second  HMMWV,  or  both,  to  trans¬ 
port  the  generator  and  other  equip¬ 
ment)  pending  further  evaluations. 
The  acquisition  plan  and  concept  for 
testing  were  approved.  The  program 
was  underway;  ten  months  had 
elapsed. 

Phase  1:  Demonstration  and 
Validation 

The  purpose  of  the  Demonstra¬ 
tion  and  Validation  phase  is  to  de¬ 
sign  the  system  and  demonstrate 
critical  processes  and  technologies. 
The  TENCAP  General  Officer  Steer¬ 
ing  Group  did  not  expect  or  require 
specific  requirements  be  met  for  the 
program  to  move  from  Phase  1  to 
Phase  2.  Consequently,  the  program 
made  no  clear  delineation  between 
demonstration  and  validation  and 
engineering  and  manufacturing  de¬ 
velopment.  This  allowed  much  work 
to  be  done  concurrently,  without 
preparing  for  a  set  of  arbitrary  mile¬ 
stones. 
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To  save  time,  the  software  System 
Requirements  Review  and  System 
Design  Review  were  combined  into  a 
Requirements  and  Architecture  Tech¬ 
nical  Interface  Meeting.  Although  the 
software  program  was  complex  (more 
than  500,000  lines  of  code),  it  was 
primarily  a  rehosting  of  existing  code 
onto  UNIX.  While  not  trivial,  it  was 
assumed  that  the  requirements  and 
structure  were  already  fairly  well-de¬ 
fined.  Unfortunately,  neither  the  con¬ 
tractor  nor  the  program  office  had 
much  UNIX  experience,  and  a  con¬ 
siderable  learning  curve  had  to  be 
overcome  in  every  phase  of  software 
development. 

In  retrospect  and  despite  an  even¬ 
tual  significant  slip  in  the  software 
development  schedule,  this  consoli¬ 
dated  approach  was  still  a  good  idea. 
There  was  probably  not  enough  UNIX 
expertise  to  do  a  such  a  thorough 
System  Requirements  Review  and 
System  Design  Review  to  justify  the 
time  and  expense  involved.  The  final 
Software  Requirements  Specification 
was  released  on  31  July  1991. 

A  directed  subcontract  should  have 
been  submitted  to  an  experienced 
UNIX  software  contractor  or,  at  the 
very  least,  an  intensive  UNIX  training 
program  for  the  software  team  and  the 
contractor’s  hiring  of  some  UNIX  ex¬ 
perts.  Some  UNIX  training  was  done 
up  front,  but  the  software  team  had 
other  TENCAP  commitments  through¬ 
out  the  development  which  prohib¬ 
ited  them  from  becuiiiing  proficient 
rapidly.  Also,  the  level  of  program 
classification  made  rapid  hiring  of 
experts  impossible. 

Our  contracting  office  issued  a 
separate  hardware  request  for  pro¬ 
posal  for  the  design  and  manufacture 
of  five  systems  immediately  after  the 
Milestone  1  decision.  The  contractor 
briefed  the  proposal  three  months 
later,  on  28  August  1991.  The  first 
inklings  of  the  challenges  of  having 
two  separate  design  teams  work  on 
the  system  became  evident  during 
fact  finding,  as  the  contractor,  in  some 


cases,  reverted  to  less-risky  solutions 
than  had  been  proposed  by  the  Army 
laboratory  and  endorsed  by  the  pro¬ 
gram  office. 

Many  of  these  differences  were  re¬ 
solved  early  in  the  process;  others 
persisted  throughout  the  program. 
Understandably,  the  contractor 
leaned  toward  a  design  with  known 
and  available  components  to  meet 
cost  and  schedule.  The  Army  Research 
Laboratory  wanted  innovative  solu¬ 
tions  using  the  latest  available  tech¬ 
nology.  The  PM  was  in  constant  arbi¬ 
tration. 

"Tie  hardware  contract  was  signed, 
and  the  contractor  received  authority 
to  proceed  in  December  1991.  De¬ 
spite  the  fact  that  the  design  was  not 
finalized,  several  long-lead-time  pur¬ 
chases  were  initiated  immediately. 
This  resulted  in  the  purchase  of  some 
excess  parts  as  the  design  matured, 
but  these  parts  were  utilized  for  spares 
on  other  systems. 

The  hardware  development  did  not 
include  a  formal  Preliminary  Design 
Review  (PDR).  Because  of  the  numer¬ 
ous  iterative  design  reviews  held  in 
the  Concept  Exploration  phase  and 
because  the  parts  purchase  process 
was  well  underway,  the  formal  PDR 
seemed  superfluous. 

Phase  2:  Engineering  and 
Manufacturing  Development 

The  purpose  of  the  Engineering 
and  Manufacturing  Development 
phase  is  to  mature  and  finalize  the 
selected  design,  validate  the  manu¬ 
facturing  and  production  processes, 
and  test  and  evaluate  the  system. 
The  primary  obstacle  in  this  phase 
was  getting  the  contractor  (who  was 
building  five  systems)  to  keep  the 
Army  Research  Laboratory  (which 
was  building  one  system  3,000  miles 
away)  informed  and  up-to-date  on 
drawings,  parts  and  design  deci¬ 
sions.  However,  this  teaming  rela¬ 
tionship  was  key  in  the  PM’s  ability 
to  influence  the  design,  processes  or 
testing. 


Involving  ’’C  Laboratory  allowed 
the  PM  to  have  an  independent  set  of 
engineers  evaluate  design  and  pro¬ 
cess  decisions  at  every  step,  and 
helped  keep  the  system  design  com¬ 
patible  with  existing  Army  systems. 
Thus,  despite  the  classification  of  the 
development,  the  system  was  not  built 
in  a  vacuum,  but  was  kept  in  step  v/ith 
mainstream  Army  components  and 
developments.  Additionally,  sophis¬ 
ticated  technologies  developed  by  the 
contractor  could  be  researched  fur¬ 
ther  and  incorporated  into  other  Army 
systems  by  the  Laboratory. 

Although  the  hardware  design  was 
still  not  final,  the  Critical  Design  Re¬ 
view  (CDR)  for  hardware  and  soft¬ 
ware  was  held  from  10-12  March  1992. 
The  TENCAP  General  Officers  Steer¬ 
ing  Group  had  approved  the  final 
configuration  of  two  HMMVWs  and  a 
trailer,  and  most  of  the  design  was  set. 
However,  the  system  was  overweight; 
the  delivery  schedule  for  some  of  the 
critical  components  were  slipping;  the 
software  design  was  behind;  and  the 
Operational  Requirements  Document 
was  not  yet  approved  (approval  came 
in  June  1992). 

The  contractor’s  design  style  was 
similar  to  a  “skunkworks.”  Engineers 
would  design  the  system  on  paper, 
but  technicians  and  engineers  build¬ 
ing  the  system  were  free  to  make 
changes  and  pursue  “good  ideas”  as 
they  were  putting  it  together.  Hence, 
the  drawings  often  lagged  behind  the 
actual  system  design. 

The  Laboratory  often  was  left  out 
of  the  information  loop  and  had  to 
scramble  to  keep  up.  This  frustration, 
coupled  with  constant  challenges  to 
contractor  design  decisions  (to  keep 
the  system  common  with  other  Army 
systems  —  something  in  which  the 
contractor  had  no  experience)  resulted 
in  occasional  hard  feelings.  For  ex¬ 
ample,  the  contractor  would  design 
and  manufacture  simple  hardware  or 
brackets  that  were  commercially  avail¬ 
able  or  even  had  National  Stock  Num¬ 
bers  assigned.  The  Laboratory  would 
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research  and  identify  the  best  part 
commercially  available  and  cause  the 
contractor  to  change  the  design. 

The  PM’s  role  of  arbitrator  and 
team  builder  was  critical.  However, 
the  checks  and  balances  imposed  by 
the  relationship  between  the  contrac¬ 
tor.  the  Laboratory,  and  the  program 
office  was  invaluable  to  the  success¬ 
ful  completion  of  the  program.  In  view 
of  the  contractor’s  skunkworks  ap¬ 
proach.  the  teaming  relationship 
proved  to  be  especially  effective  in 
vaiidating  the  manufacturing  and  pro¬ 
duction  processes  used,  and  helped 
make  the  system  reproducible  at  a 
reasonable  cost. 

Executing  the  software  contract 
continued  to  be  slow  throughout  this 
phase.  The  learning  curve  persisted 
in  every  phase  of  the  project,  and 
because  of  it  the  contractor  had  seri¬ 
ously  underestimated  the  time  (and, 
hence,  cost)  involved.  The  project  was 
further  complicated  by  the  fact  that 
the  target  system  was  not  working 
until  very  late  because  of  the  leading 
technology  hardware  chosen.  The 
software  contract  almost  doubled  in 
cost,  and  completion  was  eight  months 
late.  However,  several  critical  com¬ 
ponents  of  the  system  design  (the 
miniaturized  cryptographic  equip¬ 
ment,  the  heavy  HMMWV,  the  400- 
amp  alternator)  were  also  late,  and 
would  have  delayed  the  system  just 
as  much. 

The  system  was  tested  by  the  con¬ 
tractor  with  the  program  office  and 
Laboratory  present  in  May  and  lune 
1993.  As  would  be  expected,  many 
bugs  had  to  be  eliminated,  especially 
in  the  software  and  communications 
equipment.  The  system  then  was 
tested  at  Fort  Bragg  by  the  user  in  July. 
The  gaining  unit  personnel  were 
trained  for  30  days  by  the  contractor. 
Then,  the  U.S.  Army  Intelligence  Cen¬ 
ter  and  School  ran  a  test,  using  gain¬ 
ing  unit  personnel,  contractor  sup¬ 
port,  and  again  observed  by  the 
government  team.  The  system  was 
turned  over  to  the  319th  Military  In¬ 


telligence  Battalion  in  July  1993,  36 
months  after  Milestone  0. 

Phase  3:  Production  and 
Deployment 

The  purpose  of  the  Production  and 
Deployment  phase  is  to  produce  and 
field  the  system,  monitor  the  system 
performance,  and  support  the  fielded 
system.  This  phase  went  smoothly  — 
the  payoff  for  some  earlier  stresses. 

The  remaining  four  contractor  sys¬ 
tems  were  completed  in  rapid  succes¬ 
sion,  months  ahead  of  the  original 
schedule.  This  resulted  in  tremen¬ 
dous  cost  savings  and  almost  offset 
the  software  overrun.  Fielding  to  Fort 
Bragg,  Fort  Campbell,  Fort  Stewart 
and  Europe  went  smoothly  and  on 
schedule. 

The  Army  Research  Laboratory 
system  was  slower  to  finish  (as  ex¬ 
pected)  because  of  the  additional  work 
of  modifying  and  upgrading  the  con¬ 
tractors  documentation  to  standard 
and  making  minor  changes  to  the 
system  to  enhance  producibiJity.  This 
proved  to  be  a  large  task,  and  drawing 
inconsistencies  continue  to  surface. 
The  system  was  not  intended  to  be 
fielded  right  away.  The  original  plan 
was  to  keep  this  system  at  the  Labora¬ 
tory  until  the  ILS  package  could  be 
completed,  formal  testing  of  the  ve¬ 
hicle  and  trailer  could  be  accom¬ 
plished  at  Aberdeen  Proving  Grounds, 
and  for  work  on  advanced  technolo¬ 
gies.  However,  the  MITT  was  so  im¬ 
pressive  at  a  demonstration  given  to 
the  senior  Army  leadership  at  the  Pen¬ 
tagon  in  June  that  the  fielding  sched¬ 
ule  was  modified  and  accelerated, 
and  the  Laboratory  system  was  fielded 
to  Korea  in  January  1994. 

For  the  first  time,  ASPO  had 
fielded  a  standard  system,  with  Army 
manuals,  to  Army  divisions  world¬ 
wide.  More  importantly,  ASPO  now 
had  the  technical  data  package  and 
trained  personnel  to  help  bring  down 
the  cost  of  follow-on  builds.  A 
contract  is  being  finalized  at  the 
Army  Research  Laboratory  to 


build  five  MlTTs  with  the  develop¬ 
ment  contractor. 

Phase  4:  Operations  and 
Support 

The  Operations  and  Support  phase 
supports  the  fielded  system,  monitors 
the  system  performance,  identifies 
improvement  opportunities,  and 
modifies'upgrades.  as  required.  Here. 
ASPO  systems  have  always  excelled. 
The  ASPO  tries  to  field  the  80-percent 
solution,  and  then  uses  a  robust 
preplanned  product-improvement 
program  to  upgrade  the  system  ac¬ 
cording  to  user  feedback.  A  small  com¬ 
munity  of  users,  supported  by  con¬ 
tractor  field-service  representatives, 
allows  for  excellent  support,  feedback 
and  improvements.  Semiannual  us¬ 
ers  conferences  are  opportunities  for 
training  and  close  interface  among 
personnel  in  the  program  office  and 
the  soldiers  whom  they  support.  The 
MITT  was  phased  carefully  into  this 
program  throughout  its  development, 
and  some  particularly  vexing  prob¬ 
lems  had  already  been  presented  to 
users  for  ideas  and  prioritizing. 

Conclusion 

The  use  of  innovative  acquisition 
strategy  was  the  key  to  the  success 
of  the  MITT  program.  Involving  an 
Army  laboratory  as  an  honest  bro¬ 
ker  with  an  experienced  defense  con¬ 
tractor  resulted  in  an  impressive  syn- 
Ci yy  of  talent  tempered  by  the  checks 
ana  balances  of  divergent  interests. 
The  latest  available  technology  was 
successfully  integrated  into  a  for¬ 
ward-thinking  design.  Concurrency 
in  design,  manufacture,  testing,  field¬ 
ing  and  support  hastened  the  pro¬ 
cess  without  compromising  support- 
ability  or  producibility.  A  flexible 
approach  to  the  acquisition  mile¬ 
stones  allowed  the  program  to 
progress  rapidly  without  artificial 
barriers,  while  still  fulfilling  the  es¬ 
sence  of  the  process.  Finally,  a  ro¬ 
bust,  preplanned,  product-improve¬ 
ment  program  and  frequent,  direct 
interface  with  system  operators  al¬ 
lows  the  PM  to  be  responsive  to  user 
requirements. 
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MIL-SPECS  AND  MIL-STDS 

NO  MORE? 


DoD  Changes  Prioriliziiw  Polic\ 

o  o  ^ 


Henry  1.  Jehan,  Jr. 


Acquisition  reform  is  the  topic  of 
many  conversations.  Needed 
and  long  overdue,  this  may  be 
.  the  year  in  which  we  begin  to 
see  improvements.  The  proposed 
streamlined  contracting  procedures, 
elimination  of  restrictive  legal  and 
regulatory  requirements,  and  a  new 
focus  on  an  integrated  military/com¬ 
mercial  industrial  base  all  sound  like 
positive  changes  to  a  system  we  agree 
is  an  overburdened,  restrictive  and 
often  counterproductive  bureaucracy. 

One  effort  frequently 
championed  by  reformers  is  . 

elimination  of  military  sped- 
ftcations  (MlL-SPECs)  and 
military  standards  (MIL- 
STDs).  Once  a  critical  cornerstone 
in  fielding  an  effective  state-of-the-art 
logistically  supportable  fighting  force, 
MIL-SPECs  and  MIL-STDs  have  be¬ 
come  a  system  of  some  35,000  docu¬ 
ments.  Many  have  questionable  mili¬ 
tary  need,  such  as  MIL-SPECs  for 
chocolate  chip  cookies  and  dog 
combs.  Others  define  procedures  long 
ago  determined  technically  obsolete 
by  the  commercial  sector.  Still  others 
define  cascading  and  circular  refer¬ 
ences  from  one  document  to  another, 
often  ending  at  the  starting  point. 


Mr.  Jehan  is  the  Deputy  Project 
Manager  for  Instrumentation,  Targets 
and  Threat  Simulators  at  the  Army 
Simulation,  Training  and  Instrumen¬ 
tation  Command  (STRICOM),  Or¬ 
lando,  Fla.  He  is  a  PMC  94-1  graduate. 


Sis'' 


server,  the  Depart- 
ment  of  Defense  (DoD) 
collection  of  MIL-SPECs  and 
MIL-STDs  are  an  anachronistic  col- 
lection  of  unnecessary  bureaucratic 
documents.  Before  we  discard  them, 

however,  a  review  of  how  and  why  supporters  believe  will  result  and  dc- 
they  came  into  being  may  be  in  order,  tractors  say  cannot  be  documented. 


These  documents  evolved  to  what 
they  are  because  of  bonafide  require¬ 
ments.  Yet,  the  dialogue  1  have  heard 
on  acquisition  reform  has  not  included 
discussion  of  what  will  be  lost  if  MIL- 
SPECs  and  MIL-STDs  are  eliminated. 
Rather,  the  discussion  seems  to  cen¬ 
ter  on  a  perceived  cost  savings  that 


Cost  Controversy 

The  cost  controversy  related  to 
MIL-SPECs  and  MIL-STDs  is  based 
on  reasonable  estimates  that  they  add 
as  much  as  30  or  40  percent  to  DoD 
acquisition  costs.  Presumably,  by 
eliminating  the  MIL-SPECs  and  MIL- 
STDs.  this  cost  will  be  a  real  dollar 
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avings  in  a  time  of  declining  budgets. 
However,  this  aigument  fails  to  ex¬ 
plain  why  specifications  and  stan¬ 
dards  exist.  Not  created  for  economic 
'easons.  they  exist  because,  as  his- 
:ory  has  shown,  they  were  required  to 
'educe  combat  risk.  Simply  put,  they 
'epresent  dollars  paid  now  to  save 
i\’es  later. 


However,  these  adaptations  of  use 
by  the  commercial  sector  are  devel¬ 
oped  to  meet  civilian  needs,  not  the 
rigors  of  combat.  During  conflict,  fail¬ 
ures  of  commercial  and  improperly 
designed  military  materiel  are  not 
counted  in  monetary  costs;  they  are 
bought  with  mission  failures  and  loss 
of  human  life.  Historically,  this  price 


Some  may  contend  that  cost  is  not 
:he  only  reason  for  eliminating  MIL 
SPECS  and  MIL-STDs.  To  many. 
Dureaucracy  issues,  document  defi 
riencies,  and  burden  on  industry  are 
-idequate  justifications  to  advocate 
total  elimination  of  the  docu 
ments  in  favor  of 
using 


mercia 


standards 


However,  his 


tory  has  shown 


us  that  this  mav  be 


the  worse  possibi 


course  of  action 


The  roots  of  the  current  sys 


tern  of  specifications  and  standards 
lie  in  the  supply  fiascos  of  the  Span 
;sh-American  War,  and  a  need  for 
jood  standard  piocedures  for  pack¬ 
aging  and  preserving  supplies  and 
■naterial.  From  the  problems  experi- 
mced  in  the  field  and  at  sea.  the  MIL- 
sPECs  and  MIL-STDs  system  was 
x)m.  Subsequently,  industry  adopted 
Tiany  of  the  specifications  and  stan- 
iards.  institutionalizing  them  into 
vhat  have  become  the  commercial 
aroccdures  standards  and  specifica- 
ions  of  today. 


While 
elimiitaflng 
them  ittdy 
produce  short¬ 
term  savings, 
history  has 
shown  that 
the  long-term 
cost  of  not 
havii^  MIL- 
SPECs  and 
MIL-STDs  is  a 
price  our 
nation  has  not 
been  willing  to 
accept/ 


has  been  more  than  our  forefathers 
were  willing  to  bear.  Have  our  values 
changed  so  we  can  now  afford  such 
human  cost?  Based  on  recent  experi¬ 
ences  in  Desert  Storm.  1  would  say  not. 

Reversing  Priorities 

Department  of  Defense  leadership 
does  not  advocate  total  elimination  of 
military  standards  and  specifications. 


A  policy  memorandum  of  29  |une 
1994,  by  Dr.  William  |.  Perry.  Secre¬ 
tary  of  Defense,  states: 

Performance  sjxcifications  shall 
be  used  when  purchasing  new 
systems,  major  modifications, 
upgrades  to  current  systems, 
and  nondevelopmental  and 
commercial  items,  for  programs 
in  any  acquisition  categotv'.  If  it 
is  not  practicable  to  use  a  per¬ 
formance  specification,  a  non¬ 
government  standard  shall  be 
used.  Since  there  will  be  cases 
when  militars'  specifications  are 
needed  to  define  an  exact  de¬ 
sign  solution  because  there  is 
no  acceptable  non-gowrnmen- 
tal  standard  or  because  the  use 
of  a  performance  specification 
or  non-government  standard  is 
not  cost  effective,  the  use  of 
military  specifications  and  stan- 
diirds  is  authorized  as  a  last  re¬ 
sort,  with  an  appropriate  waiwr. 

Waivers  for  the  use  of  militar\' 
specifications  and  standards 
must  be  approved  by  the  Mile¬ 
stone  Decision  Authority  (as 
defined  in  Part  2  of  DoD  In¬ 
struction  5000.2).  In  the  case  of 
acquisition  categor\'  I  D  pro¬ 
grams,  w'aix’ers  may  be  granted 
by  the  Component  Acquisition 
Executive,  or  a  designee.  The 
Director,  Naval  Nuclear  Propul¬ 
sion  shall  determine  the  specifi¬ 
cations  and  standards  to  be  used 
for  naval  nuclear  propulsion 
plants  in  accordance  with  Pub.  L. 
98-525  (42  U.S.C.  §  7158  note). 

In  her  comments  at  the  April  25. 
1994.  Defense  Acquisition  Refonn  Sym¬ 
posium,  Mrs.  Colleen  A.  Preston. 
Deputy  Under  Secretary  of  Defense 
(Acquisition  Reform),  stated  that  the 
intent  of  DoD  policy  is  to  rex’erse  the 
priority  by  w'hich  military  and  commer¬ 
cial  standards  and  specifications  are 
incorporated  in  procurement  actions. 
Use  of  commercial  practices,  standards 
and  spiecifications  is  prioritized  ahead 
of  military  standards  and  specifications. 
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but  use  of  MlL-SPECs  and  MlL-STDs 
is  not  eliminated  completely. 

It  is  incumbent  on  personnel  in  the 
Office  of  the  Sec-etary  of  Defense, 
military  services  and  defense  agen¬ 
cies  responsible  for  implementing  this 
change  in  policy  to  ensure  that  imple- 
mer>tation  reduces  bureaucracy 
across  all  aspects  of  our  acquisition 
system,  for  both  contractor  and  gov¬ 
ernment.  Decisions  on  which  indus¬ 
try  standards,  commercial  specifica¬ 
tions,  MIL-SPECs  and  MIL-STDs 
should  be  imposed  on  a  program  are 
critical  factors  in  balancing  the  trade¬ 
offs  between  cost,  schedule  and  per¬ 
formance  with  direct  battlefield  con¬ 
sequences.  Because  they  represent 
technical  decisions,  these  factors  are 
best  evaluated  by  a  knowledgeable 
program  team  and  should  be  a  deci¬ 
sion  reserved  for  the  program  man¬ 
ager  (PM)  with  the  approval  of  the 
Milestone  Decision  Authority. 

Identifying  when  MIL-SPECs  and 
MIL-STDs  should  be  used  instead  of 
commercial  practices,  standards  and 
specifications  is  only  part  of  the  speci¬ 
fications  and  standards  problem  that 
must  be  addressed  in  each  procure¬ 
ment.  In  most  discussions  on  elimi¬ 
nating  MIL-SPECs  and  MIL-STDs, 
most  examples  come  from  the  elec¬ 
tronics  industry.  This  industry  has  an 
almost  daily  change  in  technology 
and  a  reasonably  solid  set  of  industry 
specifications  and  standards.  It  con¬ 
tends  that  MIL-SPECs  and  MIL-STDs 
are  obsolete,  references  obsolete  prac¬ 
tices  and,  to  correct  problems  in  exist¬ 
ing  contracts,  would  require  an  inor¬ 
dinate  number  of  engineering  change 
proposals  at  an  unaffordable  cost. 
Another  common  argument  has  been 
incorporation  of  a  MIL-SPEC  in  a 
contract  forces  the  contractor  to  give 
us  less  for  more,  because  the  com¬ 
mercial  sector  often  has  cheaper  prod¬ 
ucts  that  exceed  the  MIL-SPEC.  Un¬ 
doubtedly,  Dr.  Perry's  direction  gets 
to  the  core  of  these  arguments.  How¬ 
ever,  this  new  direction  may  not  cor¬ 
rect  the  perceived  problems  with  the 
standards  and  specifications. 


historically, 
we  have  done 
a  poor  jol>  of 
understanding 
and  tailoring 
the  MIL-SPECs 
and  MIL-STDs 
incorporated 
into  our 
contracts. 


A  bigger  issue  is  how  we  as  acquisi¬ 
tion  managers  employ  the  standards 
and  specifications. 

Many  MIL-SPEC  and  MIL-STD 
problems  could  have  been  corrected 
if  a  few  changes  had  been  made  in 
how  we  incorporated  them  into  our 
contracts.  Typically,  we  included  them 
by  reference  without  a  thorough  un¬ 
derstanding  of  their  content.  We  in¬ 
corporated  them  by  default,  frequently 
not  making  provision  to  change  to 
updated  versions  during  contract  per¬ 
formance.  And,  we  made  them  abso¬ 
lute  standards,  which  not  only  estab¬ 
lished  minimum  requirements  but 
often  limited  performance  as  well. 

A  New  Way  o(  EX>ing  Business 

The  new  policies  regarding  specifi¬ 
cations  and  standards  add  an  unprec¬ 
edented  level  of  importance  to  the 
PM's  responsibility  to  understand  the 
implications  of  the  specifications  and 
standards  applicable  to  the  contract. 
The  MIL-SPECs  and  MIL-STDs  rep¬ 
resent  a  historical  compilation  of  les¬ 
sons  learned,  while  commercial  speci¬ 
fications,  standards  and  procedures 
are  not  tailored  to  military  require¬ 
ments.  As  a  result,  the  PM  must  un¬ 
derstand  the  lessons  learned  captured 


in  the  MIL-SPECs  and  MIL-STDs;  the 
implications  of  the  commercial  speci¬ 
fications,  standards  and  procedures; 
and  how  these  often  incompatible 
worlds  interface  in  the  system  being 
acquired. 

Historically,  we  have  done  a  poor 
job  of  understanding  and  tailoring  the 
MIL-SPECs  and  MIL-STDs  incorpo¬ 
rated  into  our  contracts.  Mow  that  the 
use  of  MIL-SPECs  and  MIL-STDs  is 
the  exception  rather  than  the  rule,  we 
must  give  them  the  attention  they 
deserved  all  along.  If  we  must  use 
MIL-SPECs  or  MIL-STDs,  we  must 
review  and  understand  their  content 
and  intent  to  ensure  they  are  appro¬ 
priate  and  justified  before  we  incor¬ 
porate  them  into  the  contract.  Addi¬ 
tionally,  if  the  MIL-SPEC  or  MIL-STD 
is  technically  obsolete,  it  should  be 
updated  or  eliminated.  To  ensure  this, 
the  program  office  discovering  the 
inadequacy  must  become  responsible 
for  initiating  action  to  have  the  tech¬ 
nically  knowledgeable  and  respon¬ 
sible  government  organization  make 
the  needed  corrections. 

Summary 

Military  specifications  and  stan¬ 
dards  play  a  vital  role  in  our  acquisi¬ 
tion  process.  While  eliminating  them 
may  produce  short-term  savings,  his- 
toi-y  has  shown  that  the  long  term 
cost  of  not  having  MIL-SPECs  and 
MIL-STDs  is  a  price  our  nation  has 
not  bee  i  willing  to  accept. 

The  change  in  DoD  policy  to 
reprioritize  the  use  of  commercial  stan¬ 
dards,  procedures  and  specifications 
ahead  of  military  standards  and  speci¬ 
fications  is  wise.  However,  those  re¬ 
sponsible  for  implementing  this  policy 
must  ensure  the  PM  is  given  maxi¬ 
mum  flexibility  to  trade  off  the  type  of 
specifications  and  standards  used  to 
optimize  the  program.  In  doing  this, 
the  PM  must  not  lose  sight  of  the  long¬ 
term  combat  implications  of  the  stan¬ 
dards  and  specifications  used,  while 
pursuing  innovative  ways  to  reduce 
any  unnecessary  burden  imposed  on 
the  contractor. 
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FROM  OUR  READERS 


LETTER  TO  THE  EDITOR 


In  the  ian-Feb  94  issue,  the  Commandant  of  the  Defense  Systems  Management  College.  Brig  Gen 
(Sel)  Claude  M.  Bolton,  Ir.,  [USAF]  indicated  a  lack  of  understanding  of  Special  Operations  require¬ 
ments  by  those  in  the  acquisition  arena.  The  USAF  Special  Operations  School  (USAFSOS),  located  at 
Hurlburt  Field.  Florida,  could  offer  the  first  step  in  solving  this  problem.  The  mission  of  this  school  is 
to  educate  United  States  military  and  other  personnel  in  the  missions  and  functions  of  special 
operations  in  the  evolving  world  threat.  The  school  has  existed  under  various  names  since  1967.  The 
Ribbon-cutting  Ceremony  for  our  new  28,700-square-foot  educational  facility  is  scheduled  for  luly 
1994.  This  state-of-the-art  facility  will  have  two  large  auditoriums,  four  classrooms,  and  the  latest  in 
instructional  technology. 

The  USAFSOS  curriculum  has  grown  from  a  single  course  of  instruction  with  300  graduates  per  year 
to  15  different  courses  presented  72  times  per  year  with  4,000  graduates.  Courses  of  instruction  are 
divided  under  two  main  headings — Regional  Affairs  and  Special  Operations.  Regional  Affairs  courses 
include  orientation  courses  on  Latin  America,  the  Middle  East,  Africa,  and  the  Asia-Pacific  areas. 
Classes  on  cross  cultural  communications  and  antiterrorism  also  come  under  this  heading.  Special 
Operations  courses  are  more  mission  oriented  and  include  topics  such  as  an  introduction  to  Special 
Operations,  joint  planning,  revolutionary  warfare,  psychological  operations,  crisis  response,  and 
foieign  internal  defense.  Most  classes  include  a  joint  student  population  made  up  of  approximately  56 
percent  Air  Force,  19  percent  Army,  12  percent  civilian,  7  percent  Navy,  and  5  percent  from  the 
Marines.  This  joint  environment  and  a  school  policy  of  nonattribution  promote  a  forum  for  an  open 
exchange  of  ideas  and  experiences.  Many  courses  are  presented  at  the  Secret  and  Top  Secret  levels. 
Courses  often  feature  area  experts  including  ambassadors,  college  professors,  and  general  officers. 

Off-site  tutorials  are  also  available  and  can  be  tailored  to  special  needs.  We  have  a  team  that  takes 
the  Introduction  to  Special  Operations  Course  on  the  road  to  units  in  the  CONUS,  as  well  as  Kadena 
Air  Base  and  Mildenhall,  England.  This  two-day  course  addresses  the  evolution  of  Air  Force  Special 
Operations,  lUST  CAUSE  and  DESERT  STORM,  and  the  basic  missions  and  capabilities  of  Special 
Operations  units.  A  classified  case  study  of  Desert  One  is  also  included  in  this  course  which  targets  the 
audience  with  little  knowledge  of  the  Special  Operations  arena. 

All  too  often.  Special  Operations  units  are  viewed  as  performing  their  own  unique  mission  with  little 
interface  with  the  conventional  world.  The  truth  is  that  Special  Operators  actually  support  the 
conventional  war.  Because  of  this  common  misconception,  we  in  the  Special  Operations  business  are 
constantly  working  to  bridge  the  gap  between  our  forces  and  the  conventional  units.  We  hope  to 
continue  this  bridge-building  process  by  opening  the  lines  of  communication  between  USAFSOS  and 
the  Defense  Systems  Management  College. 

Continuous  changes  on  the  battlefield  and  the  evolution  of  new  missions  demand  new  and 
improved  equipment  for  Special  Operations  forces,  lust  as  the  operator  benefits  by  understanding  how 
to  function  in  the  joint  arena,  those  in  the  acquisition  process  will  undoubtedly  benefit  by  understand¬ 
ing  the  growing  demands  being  placed  on  those  in  Special  Operations.  We  at  the  USAF  Special 
Operations  School  welcome  opportunities  to  interact  with  those  in  the  acquisition  process.  Persons 
interested  in  attending  one  of  our  courses  should  contact  the  Registrar  at  DSN  579-4731  or  commercial 
(904)  884-4731. 

Colonel  Teny  R.  Silvester,  USAF 
Commandant 

USAF  Special  Operations  School 
Hurlburt  Field,  Florida 
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INSUFFICIENTLY  ROBUST 
DT&E  MEANS  TROUBLES 
AHEAD  FOR  OT&E 


n  the  fall  of  1993,  the  General  Ac¬ 
counting  Office  issued  a  report 
critical  of  how  the  Department  of 
.  Defense  (DoD)  was  managing  the 
acquisition  and  development  of  soft¬ 
ware-intensive  systems.*  At  about  the 
same  time,  the  Under  Secretary  of 
Defense  (Acquisition  and  Technol¬ 
ogy)  (USD(A&T))  asked  his  staff  how 
come  systems  pass  developmental 
testing  (DT),  and  fail  operational  test¬ 
ing  (OT).  He  then  named  five  systems 
that  were  electronic  warfare  (EVV)  and 
command,  control,  communication, 
computer,  and  Intelligence  (C^I)  sys¬ 
tems.  These  systems  are,  of  course, 
software  intensive;  thus,  the  actions 
are  addressing  the  same  issue. 

An  intensive  three-  to  four-month 
study  effort  was  initiated  to  answer 
the  USD(A8fT)  question  involving  sev¬ 
eral  organizations  and  considerable 
number  of  personnel  in  the  test  and 
other  acquisition  disciplines.  The  De¬ 
fense  Systems  Management  College 
lest  and  Evaluation  Department  par¬ 
ticipated  in  research  aimed  at  an¬ 
swering  the  question.  Conclusions 
were  presented  through  management 
and  considered  with  many  other  in- 


Profcssor  Rag  is  on  the  faculty  of  the 
Test  and  Evaluation  Department  at  the 
Defense  Systems  Management  College. 
His  more  than  35  years  of  experience 
spans  militar}',  government  and  pri¬ 
vate  aerospace  industry. 


Raymond  W.  Reig 


puts  into  the  final  re¬ 
port.  This  report  was  fonvarded  to  the 
USD(A&T)  on  25  February  1994,  and 
contained  the  following  primary  find- 
ings:’ 


My  in¬ 
volvement  with  this  study  ef¬ 
fort,  combined  with  other  experiences 
in  weapon  systems  acquisition,  have 
resulted  in  "personal  findings,”  as  fol¬ 
lows: 


—  The  requirements  generation 
and  management  process  led  to  unre¬ 
alistic  operational  requirements. 

—  Program  Developmental  Test 
and  Evaluation  (DT8fE)  was  not  suf¬ 
ficiently  robust  for  confident  entrance 
into  Operational  Test  and  Evaluation 
(OT&E). 

—  System  boundaries  were  not  de¬ 
fined  sufficiently. 


Personal  Findings 
l.The  requirements  generation  and 
justification  documents  —  the 
Operational  Requirements  Document 
(ORD)  and  the  Cost  and  Operational 
Effectiveness  Analysis  (COEA)  —  tend 
to  be  used  as  advocacy  documents 
leading  to  optimistic  expectations, 
which  are  rarely  achieved.  Research 
into  the  acquisition  historv'  of  24  DoD 
programs  shows  an  ax’erage  cost  over¬ 
run  in  the  Engineering  and  Manufac- 
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turing  Development  (EMD)  phase  of 
the  programs  to  be  45  percent,  and 
the  schedule  overrun  to  be  63  per¬ 
cent.'  A  natural  bias  seems  to  be  at 
work  here.  After  all,  no  one  proposes 
a  new  system  “just  a  little  better”  than 
the  existing  system.  So  the  pressure 
builds  for  the  super  system  that  will 
stand  head  and  shoulders  above  the 
existing  system.  This  usually  requires 
state-of-the-art  solutions  and  results 
in  notching  up  the  risk.  That  could 
take  the  form  of  adding  one  more 
requirement  to  the  existing  hard-core 


comes  to  mind  included  a  major  Pre- 
Planned  Product  Improvement  (P'l) 
consisting  at  the  time  of  a  one-  or  two- 
sentence  description  of  the  modifica¬ 
tion,  and  the  specific  threat  it  would 
defeat.  Regardless  of  the  fragile  input 
data,  the  COEA  concluded  that  the 
basic  system  with  the  P'l  was  the 
preferred  approach.  Independent  cost 
analysis  concluded  insufficient  data 
existed  to  determine  the  reasonable¬ 
ness  of  funding  profiles  of  the  basic 
program,  to  say  nothing  about  the  P'l 
program. 


Another  example  of  how  the  ORD 
and  COEA  complement  each  other  is 
the  V-22,  Tilt-Rotor  program.  The  origi¬ 
nal  COEA  used  an  opera¬ 
tional  scenario  repre¬ 
sentative  of  past  and 
current  tactics. 


ments,  thus  leading  to  the  one 
super  system  that  can  accomplish  the 
entire  requirement.  In  simpler  times, 
this  was  called  goldplating  and  engi¬ 
neers  were  accused  of  doing  it. 

Concurrently,  the  COEA  is  accom¬ 
plished  and  “confirms”  that  to  meet 
all  requirements  the  system  in  mind  is 
most  cost-effective.  TTie  COEA  that 


This  resulted  in  an  uncomfortable 
level  of  cost.  Now,  my  understanding 
is  that  a  new  COEA  is  being  created, 
using  the  newer  and  future  opera¬ 
tional  concept  of  Operational  Ma¬ 
neuver  from  the  Sea.  This  should  in¬ 
crease  the  cost-effectiveness  of  the 
system  and  may  correct  a  prior  fault, 
but  it  shows  also  how  the  ORD  and 
COEA  tend  to  self-confirm  each  other. 
Lastly,  the  DoD  5000  series  acquisi¬ 
tion  guidance  makes  the  user  resfxin- 
sible  for  creating  both  the  ORD  and 
the  COEA.  This  single  responsibility 
for  the  requirement,  as  well  as  the 
justification  of  the  selected  solution, 
is  rare  in  the  practice  of  business. 


2.  Developing  successful  software¬ 
intensive  systems  is  difficult,  because 
more  hardware  experience  and  skills 
are  available  in  industry  and  govern¬ 
ment  than  software  experience  and 
skill.  This  is  particularly  true  in  older, 
senior  personnel  who  started  their 
careers  in  the  1950s  and  1960s  —  the 
“hardware  generations.”  Back  then, 
in  large  engineering  departments 
working  on  many  programs,  one  cen¬ 
tralized  compartmented  area  existed, 
where  we  engineers  would  bring  soft- 


DT  is 

considered  a 
'low  hurdle’' 
(easy),  while 

or  is 

considered  a 
*%igh  hurdle” 
(harder).  This 
is  especially 
true  for 
software- 
intensive 
systems. 


ware  requirements  to  the  counter,  and 
were  told  when  to  return  for  the  soft¬ 
ware  program  to  integrate  into  the 
hardware  at  a  final  manufacturing 
step.  When  we  returned,  we  usually 
were  told  the  program  wasn’t  ready, 
when  to  return  again,  and  how  much 
more  funding  to  bring.  (An  over-sim¬ 
plification.  but  not  by  much.) 

Much  progress  has  been  made  in 
software  development  since  then, 
much  of  it  codified  in  MIL-STDs 
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2167A  and  21b8.  But,  hardware  engi¬ 
neers  who  used  to  bring  their  require¬ 
ments  to  the  counter  have  not  re¬ 
ceived  much  additional  training. 
Many  of  those  still  in  the  business  are 
faced  with  making  decisions  on  soft¬ 
ware-intensive  systems.  This  results 
in  managers  not  skilled  in  the  subject 
area  deciding  major  program  design 
parameters.  However,  on  balance, 
they  come  with  a  healthy  skepticism 
of  software  plans,  based  on  their  fre¬ 
quent  return  trips  to  the  sofhvare 
counter. 

3.  Avionics  software-intensive  sys¬ 
tems  are  even  more  difficult  to  de¬ 
velop  successfully,  because  airborne 
equipment  usually  has  severe  state- 
of-the-art  requirements  involving 
weight,  volume  and  cooling  air.  One 
manifestation  of  this  is  low  volume 
manufacturing  yields  of  densely  pack¬ 
aged  electronics.  The  same  card,  made 
in  the  engineering  lab  for  proof  of 
principle  tests  on  the  prototype,  did 
not  reveal  this  manufacturing  prob¬ 
lem.  This  led  to  optimistic  production 
schedules. 

Also,  unhampered  by  fact,  it  is  my 
opinion  that  avionics  software-inten¬ 
sive  systems  have  more  interfaces  than 
stabile  ground  systems.  Shortcomings 
are  more  apt  to  be  discovered  in  OT 
end-to-end  testing  than  in  prior  in  situ 
DT  testing.  For  example,  a  standard 
radio  designed  to  operate  in  many 
aircraft  types  may  p)erform  differently 
in  different  platforms  because  of  the 
type  and  placement  of  the  antennae 
in  the  various  platforms,  particularly 
in  fighter  aircraft  vs.  transport  aircraft. 

4.  The  EW  and  Cl  avionics  soft¬ 
ware-intensive  systems  are  the  most 
difficult  to  develop  successfully.  In 
addition  to  the  constraints  previously 
discussed,  these  systems  usually  re¬ 
quire  stringent  special  personnel  se¬ 
curity  clearances,  over  and  above 
those  required  for  other  military  de¬ 
velopment  projects. 

In  the  late  1960s  and  early  1970s, 
the  “software  generations”  were  just 


graduating  with  the  prerequisite  skills 
desperately  needed  but.  to  a  certain 
percentage,  using  their  skills  for  the 
military  was  anathema.  Any  involved 
in  college  student  protests  probably 
would  not  be  granted  the  required 
clearance.  Besides,  the  alternative  was 
employment  in  Silicon  Valley  and  else¬ 
where  with  modern  working  condi¬ 
tions  and  attractive  pay.  It  seemed 
more  inviting  than  working  at  a  green 
or  gray  steel  desk  in  an  engineering 
bullpen  at  some  defense  contractor  or 
government  laboratory. 

Also,  the  EW  and  Ci  systems  were 
being  designed  to  defeat  a  threat  that 
was  not  static,  not  under  our  control, 
or  perhaps  not  even  known  to  us.  In 
the  8-10  years  it  takes  to  design,  de¬ 
velop  and  produce  our  system,  if  the 
threat  has  increased,  our  production- 
ready  system  may  have  limitations. 
This  comes  close  to  being  a  law  of 
physics  and  the  only  solution  1  can 
think  of  is  a  PT  or  evolutionary  acqui¬ 
sition  approach. 

5.  Perhaps  because  of  the  aforemen¬ 
tioned  aspects,  software-intensive 
systems  receive  extramanagerial  in¬ 
puts,  above  and  beyond  the  program 
manager's  control.  Examples  listed 
here  are  all  from  one  program,  but 
these  and  others  do  occur  with  some 
frequency.  In  this  program,  the  Ser¬ 
vice  Secretary  abruptly  requires  un- 
planned-for  testing,  and  adjusts  the 
budget  insufficiently.  Another  Service 
withdraws  from  this  joint  program, 
and  Congress  limits  the  use  of  pro¬ 
duction  funds.  Contracting  directs  the 
procurement  of  a  critical  subsystem 
from  a  specific  source,  and  later  caps 
the  government  program  costs  at  a 
figure  substantially  below  actual  costs. 
Most  recently,  the  Service  has  been 
directed  to  conduct  no  more  OT  until 
a  Director  of  Operational  Test  and 
Evaluation,  has  been  appointed. 

6.  In  systems  of  this  type  a  move¬ 
ment  seems  to  exist  toward  “creative 
terminology”  which  confounds  the 
established  program  evaluation 
metrics.  1  believe  most  people  who 


have  been  in  the  defense  industry'  for 
any  period  of  time  have  a  good,  ho¬ 
mogeneous  interpretation  of  the  terms 
Low  Rate  Initial  Production  (LRIP). 
Operation  Evaluation  (OPEVAL).  Full 
Rate  Production,  and  Initial  Ofvra- 
tional  Capability  (IOC).  Generally, 
they  are  familiar  with  the  require¬ 
ments  of  each,  and  many  of  these 
requirements  are  contained  within  the 
DoD  5000  series  documentation.  Re¬ 
cently,  some  programs  approaching 
these  milestones,  but  not  quite  able  to 
meet  the  requirements  thereof,  have 
used  alternative  terminology.  Hence, 
an  LRIP  phase  becomes  a  PV  (prod¬ 
uct  verification)  phase,  or  an  OPEVAL 
becomes  an  “Operational  Effective¬ 
ness  Test”  or  a  “Verific  ■  of  Cor¬ 
rection  of  Deficiencies  T  c  IOC. 

in  some  cases,  has  bee  eed  by 
Limited  Operational  Capai  iniy  (LOC). 
Many  people  would  know  how  to 
evaluate  an  OPEVAL,  or  judge  readi¬ 
ness  for  an  LRIP  phase,  but  no  guid¬ 
ance  is  found  on  how  to  evaluate,  or 
what  to  expect  from,  these  newer 
terms. 

Then  the  question  remains  regard¬ 
ing  wording  used  within  a  TEMP  or 
test  report.  One  sentence  from  a  test 
result  used  in  a  program  TEMP  stated 
“For  the  tests  performed  the  system 
operated  as  required.”  Is  this  good  or 
bad?  Another  variation  of  the  same 
idea  is  to  list  a  large  number  of  limita¬ 
tions  of  scope  on  the  testing  performed, 
and  then  provide  a  generalized  evalu¬ 
ation  which  makes  the  results  of  lim¬ 
ited  usefulness.  Currently  a  program 
is  considering  declaring  IOC  before 
Milestone  111,  upon  delivery  of  the 
first  LRIP  article.  Clearly,  this  is  a 
different  interpretation  of  the  IOC  than 
that  of  a  few  years  ago. 

7.  In  my  opinion,  subject  to  objec¬ 
tive  confirmation,  it  seems  that  few 
test  articles  have  been  used  in  the 
EiMD  phase,  relative  to  the  total 
planned  production  quantity.  In  the 
ongoing  research  into  the  EMD  phase 
of  recent  weapon  systems  acquisi¬ 
tions.  an  average  of  1.8  percent  of  the 
total  planned  production  quantity  or 
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28  percent  of  the  total  LRIP  quantity 
was  acquired  with  research,  develop¬ 
ment,  test  and  evaluation  funds  and 
presumably  used  for  testing.  Of  the 
five  programs  used  as  examples  in 
USD(A&T)  questions,  the  average 
number  of  LRIP  articles  used  for  test¬ 
ing  was  1 .3  percent  of  the  total  planned 
production  quantity.^ 

Recommendations 

The  price  for  commenting  on  a 
process  is  to  recommend  actions  to 
ameliorate  the  situation.  Mine  are  as 
follows: 

1.  If  someone  could  solve  the  soft¬ 
ware  development  problem,  half  of 
our  systems  acquisition  problems 
would  be  solved.  Our  usual  approach 
is  to  reorganize  or  change  the  acquisi¬ 
tion  policy.  I  surest  a  complemen¬ 
tary  approach  whereby,  for  the  next 
five  years,  a  mandatory  special  soft¬ 
ware  acquisition  management  course 
could  be  held  for  all  senior  managers 
involved  in  DoD  acquisition.  The  tar¬ 
get  audience  would  be  the  still-active 
hardware-generation  managers. 
Waivers  would  be  available  for  the 
software  proficient,  and  younger  man¬ 
agers  who  want  more  software  train¬ 
ing  would  be  welcome.  After  five  years 
the  problem  should  be  self-correct¬ 
ing,  and  the  special  course  could  be 
terminated. 

The  Air  Force  Bold  Stroke  course  is 
an  excellent  example.  This  is  a  one- 
week  course  designed  for  general  of¬ 
ficers.  and  its  objective  is  to  increase 
the  awareness  of  these  senior  manag¬ 
ers  to  software  acquisition  pitfalls. 
This  course,  originally  designed  by 
DSMC  for  the  Air  Force  Systems  Com¬ 
mand,  is  now  presented  by  the  Pro¬ 
fessional  Development  Institute. 

2.  Distinguish  between  a  “broken” 
acquisition  system  and  a  poorly  ex¬ 
ecuted  program.  In  the  24  systems 
reviewed,  18  were  tightly  grouped 
somewhat  over  the  original  HMD  cost 
and  schedule  estimates,  and  six  were 
significantly  outside  the  range.  I  would 
say  the  current  acquisition  system 


provides  results  similar  to  the  results 
of  18  of  these  programs,  and  six  of 
these  programs  were  poorly  executed. 
The  reasons  for  poor  execution  are 
many  and  diverse,  and  probably 
caused  as  much  by  conditions  out¬ 
side  the  program  office  as  those  within. 

3.  Instill  discipline  in  the  established 
acquisition  system.  The  current  offi¬ 
cial  guidance  governing  DoD  acquisi¬ 
tion,  the  5000  series  documentation, 
was  issued  in  February  1991.  Merely 
reading  and  knowing  the  5000  series 
intimately  would  not  suffice  three 
years  later.  The  conclusions  of  a  dozen 
or  more  OSD  memos,  immediately 
directive  in  nature,  indicate  that  the 
subject  matter  will  be  incorporated 
into  the  next  Directives  update.  To 
date,  this  has  not  happ)ened. 

The  Directives  state  the  Test  and 
Evaluation  Master  Plan  is  limited  to 
30  pages,  plus  annexes.  Providing  the 
data  currently  required  by  OSD  re¬ 
viewers  and  others  within  30  pages  is 
not  possible.  Much  of  the  additional 
required  data  is  valuable,  and  per¬ 
haps  the  answer,  in  this  instance,  is  to 
review  the  page  limitation.  Creative 
terminology,  discussed  previously, 
falls  into  this  category  of  system  disci¬ 
pline. 

4.  Consider  the  then-current  prac¬ 
tices  when  post'facto  criticizing  a 
program’s  performance.  I  believe  the 
A- 12  Administrative  Inquiry  contains 
an  eloquent  exposition  of  this  point.’ 

The  above  thoughts  were  generated 
by  my  involvement  in  recent  research 
efforts  associated  with  acquisition, 
and  by  longer-standing  experience.  I 
hope  it  agrees  generally  with  your 
own  thoughts,  and  you  find  it  worth¬ 
while.  The  Test  and  Evaluation  De¬ 
partment  research  is  ongoing  and 
other  resulting  data  will  be  published 
in  subsequent  articles. 
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MANAGING  A  MAJOR 
TECHNICAL  PROGRAM 


Comparisons  in  Dealing  wilh  Chango 


llthough  it  is  not  a  military  system. 
■  the  Space  Station  Freedom  Pro- 
11  gram  (SSFP)  provides  some 
11  interesting  technical  and  man¬ 
agement  comparisons  in  dealing  with 
the  changes  of  a  major  technical  pro¬ 
gram. 

The  space  station  program  is  a 
major  technical  effort  involving  fund¬ 
ing  of  approximately  $2  billion  yearly. 
Scheduled  for  completion  around  the 
year  2000.  the  program  is  global  and 
includes  international  partners  from 
lapan.  Canada  and  the  European 
Space  Agency.  It  also  includes  work 
with  Russia.  The  closest  comparison 
to  a  military  program  office  would  be 
that  of  a  joint  program  office  with 
participation  of  allied  forces. 

This  article  will  make  some  com¬ 
parisons  of  the  National  Aeronautics 
and  Space  Administration  (NASA) 
SSFP  with  two  major  military  devel- 
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opment  activities:  i.e.,  submarine  con¬ 
struction  and  the  work  of  the  Strategic 
Defensive  Initiative  (SDI).  General 
comparisons  are  made  between  the 
military  and  NASA  program  life  cycles. 
Comparisons  are  shown  in  software 
management  in  the  NASA  SSFP  with 
military  software  management.  Life- 
cycle  organizational  change  compari¬ 
sons  are  made. 

The  configuration  of  Space  Station 
Freedom  (SSF)  has  changed  many 
times  during  its  development  cycle. 


The  version  in  the  photograph  is  a 
restructured  design  concept.  Like  mili¬ 
tary  programs,  constant  pressures  to 
cut  costs  exist.  Even  with  major  re¬ 
structuring  to  save  money  the  space 
station  has  general  features  still  in¬ 
cluding:  a  Truss  for  mounting  station 
elements;  a  U.S.  laboratory  module;  a 
habitation  module;  an  airlock  en¬ 
abling  transfer  of  crew  and  equip¬ 
ment  between  pressurized  and 
unpressurized  areas;  major  sub¬ 
systems  for  providing  power,  thermal 
control,  data  handling,  environment 
control  and  life  support;  Canadian 
rail-mounted  mobile  transporter;  pres- 
2  surized  and  unpressurized  logistics 
^supply  elements:  a  Japanese  experi- 
®  ment  module,  and  a  European  Space 
o  Agency  attached  pressurized  module 
a  for  laboratory  work. 

£ 

Like  the  military,  adversaries  sud¬ 
denly  can  become  friends.  With  the 
collapse  of  the  Cold  War,  negotia¬ 
tions  are  now  underway  to  use  the 
Russian  Soyuz  spacecraft  as  a  “life¬ 
boat”  for  emergency  crew  return.  Plans 
also  continue  for  considering  further 
changes  that  involve  greater  coopera¬ 
tion  with  the  Russian  Space  Station 
Mir  program. 

Comparison  with 
Submarine  Construction 

Commander  S.M.  Jarrett  in  his  Na¬ 
val  War  College  paper,  "The  Applica¬ 
tion  of  Submarine  Experience  and 
Technology  to  the  Space  Environ¬ 
ment,”  pointed  out  that  the  subma¬ 


rine  force  of  the  United  States  has 
opjerated  in  a  closed  environment  for 
almost  80  years.  Further,  he  stated 
that  submarine  patrols  simulate  space 
travel  more  closely  than  any  other 
type  of  operation.' 

Developing  and  constructing  a  sub¬ 
marine,  however,  differs  from  devel¬ 
oping  and  constructing  the  SSF.  For 
example,  the  SSF  Environmental  Con¬ 
trol  and  Life  Support  System  (ECLSS) 
has  atmosphere  control  and  supply, 
nitrogen  support,  pressurized  element 
temperature  and  humidity  control,  at¬ 
mosphere  revitalization,  and  fire  de¬ 
tection  and  repression.  Designed  to 
be  a  distributed  system,  the  equip¬ 
ment  will  be  assembled  in  space  dur¬ 
ing  several  shuttle  flights.  Figure  1 
shows  an  example  of  the  ECLSS  dis¬ 
tributed  systems  lines  and  other  dis¬ 
tributed  system  lines  that  need  to  be 
connected  in  space  between  a  node 
and  module  sent  up  on  different  flights. 

In  submarine  development  and 
construction,  the  life-support  systems 
are  designed  to  be  assembled  at  a 
naval  shipyard  with  all  the  conve¬ 
niences  of  a  permanent  facility.  Al¬ 
though  the  ECLSS  system  has  had 
some  shuttle  carryover  in  technology, 
it  has  been  designed  as  a  completely 
new  system.  By  comparison,  in  a  sub¬ 
marine  program,  changes  to  a  system 
are  more  gradual.  A  new  class  of  sub¬ 
marine  might  be  built,  for  example, 
with  no  major  changes  in  the  life- 
support  system. 


FIGURE  1.  SSF  Distributed  Systems  Connections. 
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Although  differences  exist  between 
development  and  construction  for 
operations  in  space  vs.  underwater, 
Commander  Jarrett,  in  his  thesis,  dis¬ 
cusses  opportunities  for  sharing  tech¬ 
nologies.  This  type  of  cooperation  can 
benefit  both  the  NASA  and  military 
program  managers  (PMs). 

Comparison  with  the 
SDl  Program 

The  SDI  (renamed  the  Ballistic 
Missile  Defense  Organization),  a 
major  military  program,  has  seen 
many  changes.  Even  with  the  current 
emphasis  on  ground  defense  systems, 
the  program  involves  on-orbit  space¬ 
craft  and  is  useful  for  making  com¬ 
parisons  with  the  SSFP.  Like  the  SSFP, 
the  SDI  has  an  annual  budget  in  bil¬ 
lions  of  dollars  and  involves  many 
government  organizations  and  con¬ 
tractors. 

The  SDI  military  mission  has  been 
to  develop  a  defense  against  nuclear 
missile  attack.  Space-based  satellites 
in  the  defense  system  are  used  to  spot 
launches,  track  taigets,  prioritize  and 
control  kills.  The  weapons  for  kills 
may  be  space  or  ground  based.  Al¬ 
though  astronauts  may  be  military 
and  the  experiments  may  be  of  use  to 
military  research,  the  space  station  is 
not  a  part  of  any  weapons  system. 

The  space  station  program  will  have 
men  permanently  stationed  in  space. 
On  the  other  hand,  the  SDI  program 
does  not  involve  permanent  presence 


in  space  to  operate  the  system.  Space 
Station  Freedom  has  a  long-term  mis¬ 
sion  in  space  of  15  years  or  more.  The 
SDI  has  a  long-term  commitment  to 
protect  our  nation’s  assets  from  mis¬ 
sile  attack,  but  it  would  not  necessar¬ 
ily  have  to  have  the  same  spacecraft 
in  orbit  for  long  periods  of  time.  Should 
an  SDI  element  have  a  long-term  pres¬ 
ence  in  space,  it  can  learn  from  the 
space  station’s  designs  and  operating 
experiences  in  on-orbit  maintenance 
involving  robotics  and  manned  extra¬ 
vehicular  activities. 

Both  being  major  billion  dollar  pro¬ 
grams,  the  space  station  program  and 
the  SDI  have  been  in  the  public  eye 
constantly  and  open  to  public  attack. 
Throughout  the  program  life  cycle, 
critics  present  other  systems  and  ways 
to  spend  the  money,  and  may  time 
their  attack  to  just  before  congres¬ 
sional  hearings.  'iTie  PM  may  not  have 
much  time  to  respond  to  a  headline  in 
the  morning  newspaper  when  hear¬ 
ings  begin  the  same  or  following  day. 
Generally,  the  PM  must  be  aware  of 
these  critics  in  advance  in  order  to 
best  defend  his  program  decisions. 
Sometimes  public  debate  may  be  nec¬ 
essary.  Program  officers  must  make 
no  out-of-place  remarks  or  those  that 
can  be  misinterpreted. 

Major  programs  like  SSF  and  the 
SDI  seek  technical  and  programmatic 
advice  from  many  consultants  and 
outside  experts.  Generally,  these 
people  come  under  two  categories  — 


those  under  PM  control  and  indepen¬ 
dent  experts  chosen  by  others  at  higher 
levels  including  the  President  and 
Congress.  Those  in  the  first  category 
can  be  a  big  help  in  resolving  prob¬ 
lems  where  the  existing  organizational 
staff  is  deficient  in  capabilities  saving 
time,  money  and  improving  quality. 
Those  ir.  the  second  category  often 
require  the  PM  to  divert  precious 
manpower  into  gathering  information 
for  the  expe.ris. 

A  negative  report  by  the  experts 
can  hurt  the  PM’s  career.  In  addition, 
the  results  of  independent  studies  limit 
the  PM’s  decision-making  flexibility. 
In  one  case  in  the  space  station  pro¬ 
gram,  the  outside  consultants  were 
not  pleased  with  the  reception  their 
study  received  by  the  program  man¬ 
agement.  To  strengthen  thei;  point, 
the  consultants  released  their  views 
to  the  New  York  Times.  This  forced 
the  program  to  move  in  the  direction 
desired  by  the  consultants. 

Lobbying  the  Congress  is  not  an 
option  of  a  NASA  or  military  PM, 
even  though  Congress  with  its  larger 
support  staffs,  tends  to  be  moving 
beyond  establishing  policy  and  fund¬ 
ing  legislative  work  to  directing  pro¬ 
gram  office  actions.  Program  contrac¬ 
tors  can  lobby  the  Congress.  For 
example,  a  contractor  might  place  an 
advertisement  strategically  in  the 
Washington  Post  just  before  a  con¬ 
gressional  hearing.  Even  unions  can 
help  the  PM  promote  his  program.  In 
both  cases,  however,  the  PM  has  no 
control  over  what  they  say  or  their 
priorities.  The  PM’s  best  defense  for 
his  program  is  a  good  presentation  at 
the  congressional  hearings  and  to  be 
trusted. 

Comparison  of  Program 
Life-Cycle  Phases 

The  military  program  life  cycle  and 
the  NASA  life  cycle  have  different 
terms  and  groupings  for  the  program 
phases  as  shown  in  Figure  2.  The 
military  groups  the  program  life  cycle 
into:  the  Pre-Milestone  0  Activities, 
Concept  Exploration  and  Definition, 


FIGURE  2.  Comparison  of  the  NASA  Program  Cycle 
with  the  Defense  Program  Cycle 
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Demonstration  and  Validation,  Engi¬ 
neering  and  Manufacturing  Develop¬ 
ment.  Production  and  Deployment, 
Operations  and  Support  and,  finally. 
Disposal.  The  phases  apply  to  all  types 
of  weapon  systems  from  helicopters 
to  ships,  tanks  and  satellites. 

The  NASA  program  life  cycle  is 
geared  ultimately  .u  launching  some¬ 
thing  into  space  and  retrieving  infor¬ 
mation  from  the  space  activities.  The 
NASA  program  phases  are  termed: 
Phase  A,  Mission  Needs  and  Concep¬ 
tual  Studies;  Phase  B,  Concept  Defi¬ 
nition  and  Preliminary  Design:  Phase 
C,  Design  and  Development,  leading 
to  Critical  Design  Review:  Phase  D, 
Fabrication,  Integration,  Test  and 
Certification;  Phase  E,  Pre-Opera¬ 
tions,  including  deployment  and  per¬ 
formance  validation;  Phase  F,  Opera¬ 
tions  and  Disposal,  including 
sustaining  engineering  and  phase 
out.  The  program  is  currently  in  Phase 
C  with  partial  work  being  done  in 
Phase  D. 

In  both  NASA  and  the  military 
program  cycles,  change  flexibility  be¬ 
comes  more  confining  as  the  program 
cycle  progresses,  because  decisions 
made  continually  reduce  options  and 
alternatives.  This  is  true  particularly 
as  hardware  production  begins  and 
software  is  in  advanced  testing.  Like 
the  military,  NASA  must  respond  to 
threats  and  opportunities  as  the  life 
cycle  unfolds.  Military  programs  usu¬ 
ally  are  impacted  by  changing  threats 
from  external  military  powers.  The 
NASA  threats  tend  to  be  related  to 
things  like  funding  indecision.  For 
example,  if  a  heavy  lift  vehicle  is  not 
funded  for  SSFP  use,  more  shuttle 
flights  will  be  needed  to  get  the  total 
number  of  payloads  into  space.  Soft¬ 
ware  phases  differ  somewhat  from  the 
phases  just  described,  as  the  follow¬ 
ing  section  will  explain. 

Software  Management 
Comparisons 

The  System  Software  Development 
Standard  (DoD-STD-2167A)  applies 
directly  to  military  software  develop¬ 


ment.  In  NASA,  DoD-STD-2167A  pro¬ 
vides  supporting  and  background  in¬ 
formation  but  is  not  a  requirements 
document.  The  NASA  Software  Man¬ 
agement  and  Assurance  Program 
(SMAP),  out  of  the  Office  of  Safety, 
Reliability,  Maintainability  and  Qual¬ 
ity  Assurance,  has  created  standards 
documentation  called  the  “Informa¬ 
tion  System  Life-Cycle  and  Documen¬ 
tation  Standards.”  The  SSFP  has  used 
these  standards  including  many  of 
the  NASA  Data  Item  Descriptions  in 
its  management  planning  and  require¬ 
ments  development. 

A  distinction  between  military  and 
NASA  management  in  software  and 
hardware  development  is  that  in 
NASA  consensus  of  management  is  a 
more  dominant  influence  than  fol¬ 
lowing  a  strict  set  of  regulations.  The 
military  rotating  assignments  create  a 
greater  need  for  following  formal 
directives  and  standards.  In  NASA, 
employees  remain  for  long  time 
periods  and  have  considerable  influ¬ 
ence  in  new-program  decision  mak¬ 
ing.  In  the  case  of  the  SSFP,  experi¬ 
ences  of  shuttle  program  personnel 
have  had  a  strong  impact  on  SSFP 
software  requirements  and  manage¬ 
ment  practices. 

One  example  of  the  influences  of 
previous  experiences  is  the  SSFP 
Flight  Systems  Software  Requirements 
(FSSRs).  Unlike  DoD-STD-2167A, 
which  sets  requirements  by  individual 
Computer  Software  Configuration 
Items  (CSCIs),  the  FSSRs  set  require¬ 
ments  by  systems  which  may  have 
several  CSCIs.  What  is  gained  by  a 
systems  perspective,  however,  is  off¬ 
set  by  the  greater  difficulty  in  judging 
the  maturity  of  requirements  com¬ 
pared  to  evaluating  individual  CSCIs. 

Many  of  the  contractors  that  work 
software  development  for  the  SSFP 
have  experience  based  on  military 
software  systems.  They  tend  to  follow 
the  military  standards  like  DoD-STD- 
2167A  whenever  they  can,  thereby 
providing  another  source  of  influence 
on  NASA  procedures. 


Working  Avionics  Problems 

The  SSFP  software  development 
management,  software  engineering 
and  software  test  and  evaluation  re¬ 
sponsibilities  fall  under  the  same 
groups  that  work  avionics  problems. 
For  example,  the  largest  software  ef¬ 
fort  in  SSFP  is  the  Data  Management 
System  (DMS)  which  is  organization¬ 
ally  placed  under  Avionics  Systems. 
Before  restructuring  to  reduce  costs, 
the  DMS,  including  applications  soft¬ 
ware,  had  more  than  one  million  lines 
of  code  required  to  integrate,  test, 
verify  and  maintain  the  system.  The 
DMS  uses  1,553  data  bus  architec¬ 
ture.  For  example,  the  system  con¬ 
trols  sensors  and  effectors  in  pointing 
an  antenna,  through  the  use  of  Multi¬ 
plexer  Demultiplexers  (MDMs). 

Organizationally,  SSFP  Avionics 
includes  the  DMS,  Communications 
and  Tracking  System  (C&T)  and  Guid¬ 
ance,  Navigation  and  Control 
(GN&C).  Other  systems  such  as  the 
Electrical  Power  System  (EPS),  and 
the  Environment  Control  Life  Sup¬ 
port  System  (ECLSS),  for  example, 
are  not  in  Avionics  Systems  but  re¬ 
quire  software  controls.  These  sys¬ 
tems  rely  on  the  software  community 
for  software  engineering  and  testing 
support.  Because  they  are  in  different 
organizations,  more  integration  is  re¬ 
quired  than  where  the  system  is  di¬ 
rectly  in  avionics. 

Software  Configuration  Manage¬ 
ment  (CM)  in  the  SSFP  does  not  fol¬ 
low  DoD-STD-2167A.  Requirements 
for  CM  are  patterned  after  the  space 
shuttle  program.  Software  change 
control  and  hardware  change  control 
follow  traditional  CM  procedures  of 
establishing  configuration  identifica¬ 
tion,  configuration  control,  status  ac¬ 
counting  and  verification. 

Baseline  distinctions  like  func¬ 
tional,  allocated  and  product  are  not 
followed  rigorously.  The  main  Soft¬ 
ware  Change  Control  Board  for  the 
SSFP  has  been  located  physically  at 
the  NASA  center  having  the  most  soft¬ 
ware  expertise.  This  board  has  had 
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baselining  authority.  However,  if  a 
software  issue  is  sufficiently  contro¬ 
versial,  particularly  in  terms  of  cost 
impacts,  the  Change  Request  will  be 
brought  up  to  the  Space  Station  Con¬ 
trol  Board  —  the  main  board  for  all 
changes. 

Requirements  for  software  quality 
assurance  generally  include  the  es¬ 
sentials  of  DoD-STD-2167A,  although 
some  differences  exist.  For  example, 
in  the  software  product  assurance 
evaluation  of  nondevelopmental  soft¬ 
ware  (NDS),  the  military  and  SSFP 
both  want  evidence  that  the  NDS 
works,  that  it  is  under  configuration 
management,  and  that  data  rights  are 
consistent  with  the  contract.  The  DoD- 
STD-2167A  goes  further,  requiring 
government  approval  to  use  NDS; 
otherwise,  their  documentation  re¬ 
quirements  apply. 

Figure  3  shows  an  example  of  sys¬ 
tem  development  reviews  for  software/ 
hardware  development  in  the  mili¬ 
tary.  The  diagram  is  from  DoD-STD- 
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2167A  with  the  addition  of  a  systems 
engineering  timeline.^  The  NASA  and 
military  software  and  hardware  are 
developed  in  parallel.  The  diagram 
shows  military  hardware  and  soft¬ 
ware  being  integrated  at  major  mile¬ 
stones  such  as  Preliminary  Design 
Review  (PDR)  and  Critical  Design 
Review  (CDR). 

In  the  SSFP  case,  the  software 
major  reviews  are  staggered  later  than 
the  hardware  major  reviews.  This  al¬ 
lows  the  software  developers  to  see 
the  hardware  detail  before  they  final¬ 
ize  their  codes.  This  makes  sense  in 
terms  of  system  safety.  Software  alone 
is  not  safe  or  unsafe.  However,  if  there 
are  some  wrong  assumptions  made  in 
writing  the  codes  about  the  opera¬ 
tions  of  the  hardware,  safety  could  be 
affected. 

In  the  SSF  Man  Tended  Capability 
CDR,  for  example,  software  people 
were  well  represented  and  they  made 
status  presentations.  The  software, 
however,  was  not  baselined  at  that 
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time.  Thus,  the  software  people  were 
able  to  evaluate  carefully  the  hard¬ 
ware  with  which  they  would  be  work¬ 
ing  before  they  baselined  the  soft¬ 
ware.  Eventually,  hardware  and 
software  must  be  teste '  together  in 
both  NASA  and  military  systems,  simi¬ 
lar  to  the  right  side  of  the  diagram. 

Life-Cycle  Organizational 
Change  Comparisons 

In  the  military  and  in  NASA  major 
programs,  the  expectation  is  that  or¬ 
ganizational  changes  will  occur  as 
the  program  shifts  to  new  phases. 
Organization  changes,  can  help  cre¬ 
ate,  in  a  better  way,  products  ex¬ 
pected  from  the  succeeding  phases. 

The  SSFP  organizational  history 
goes  back  to  the  early  1980s.  In  the 
conceptual  stage  (Phase  A)  the  orga¬ 
nization  began  as  a  small  task  force, 
which  funded  studies  on  attributes, 
architectural  options  and  interna¬ 
tional  participation.  Similar  to  the 
military,  a  working  group  was  estab¬ 
lished  to  set  mission  requirements.  In 


Program  Manager 


20 


July-Augusr  1994 


the  mid- 1980s,  the  President  intro¬ 
duced  the  space  station  program  to 
the  nation  including  the  intent  for 
international  participation. 

Phase  B  began  with  an  organiza¬ 
tional  pattern  that  differs  from  a  DoD 
approach.  Definition  studies  were  di¬ 
rected  not  by  a  central  organization 
but  by  four  NASA  centers.  Results  of 
the  work  of  eight  definition  contrac¬ 
tors  were  worked  into  Requests  for 
Proposals  (RFPs)  which  were  issued 
and  controlled  by  the  four  NASA  cen¬ 
ters.  In  Phase  B,  NASA  Headquar¬ 
ters,  working  with  the  State  Depart¬ 
ment,  established  Memoranda  of 
Understanding  with  Canada,  Japan 
and  the  European  Space  Agency. 

Phase  C  organization  was  influ¬ 
enced  by  the  Challenger  accident.  A 
post-Challenger  investigation  recom¬ 
mended  that  better  control  could  be 
achieved  by  having  the  program  of¬ 
fice  near  NASA  Headquarters  in 
Washington,  D.C.  Thus,  a  formal  pro¬ 
gram  office  structure  was  established 
as  shown  in  Figure  4.  A  three-tier 
program  office  included  Level  I  and 
Level  II  offices  located  in  the  Wash¬ 
ington,  D.C.,  area  and  Level  III  Of¬ 
fices  located  at  the  NASA  centers. 

The  organization  was  made  laige 
in  order  to  provide  the  design  detail 
needed  for  CDR.  Overall,  2,300  civil 
servants  worked  directly  or  matrixed 
to  the  program.  These  included  292 
NASA  contractors  and  117  interna¬ 
tional  partner  contractors.  The  prime 
contractors  still  reported  to  the  NASA 
centers  through  the  Level  III  organi¬ 
zations.  Figure  5  shows  only  three 
prime  contractors,  since  early  in  Phase 
C  Work  Package  III  was  abolished. 

The  Level  I  organization,  a  small 
office,  worked  overall  policies  with 
NASA  Headquarters,  coordinated 
with  the  Congress,  and  provided  over¬ 
all  program  direction.  The  Level  II 
organization  had  approximately  250 
civil  servants  supported  by  an  inte¬ 
grating  contractor  with  approximately 
850  people.  Top-level  baseline  re¬ 


quirements  control  was  worked  by 
Level  11.  Organizational  elements  in¬ 
cluded:  program  engineering,  utiliza¬ 
tion  and  operations,  management  in¬ 
tegration,  international  programs, 
integration,  safety  and  product  assur¬ 
ance  and  program  control.  The  inter¬ 
national  partners  had  their  main  inte¬ 
gration  offices  located  at  Level  II. 

Early  in  Phase  C,  top  NASA  man¬ 
agement  began  looking  ahead  to  the 
organization  needed  for  succeeding 
phases.  Development  and  fabrication 
contracts  eventually  were  scheduled 
to  be  tapered  off  and  replaced  by 
contracts  for  operation  and  utiliza¬ 
tion  of  the  space  station,  and  a  new 
organization  would  be  needed.  The 
new  activities  were  expected  to  be 
NASA  center  oriented  involving  pay- 
load  planning,  logistics,  launch  op¬ 
erations  and  station  operations. 

The  feeling  was  that  a  large  Wash¬ 
ington-based  program  office  was  not 
needed  for  these  activities.  A  smaller 
office  located  on  one  of  the  centers, 
with  people  focused  more  on  utiliza¬ 
tion  and  operations,  was  anticipated. 
The  situation  might  be  somewhat 
analogous  to  the  Air  Force  approach 
in  the  past  to  moving  a  program  from 
a  development  command  to  a  logis¬ 
tics  command.  When  and  where  was 
not  established. 


The  NASA,  like  the  military,  is  sub¬ 
ject  to  budget  pressures,  administra¬ 
tion  changes,  reactions  to  cost  over¬ 
runs,  and  world  politics.  These  factors 
made  the  SSFP  a  taiget  of  technical 
and  organization  change  before  Phase 
C  was  completed.  The  uprooting  in¬ 
cluded  technical  and  management 
changes.  Technically,  some  parts  of 
the  program;  i.e.,  structure  and  mass 
properties  analysis,  had  to  revert  back 
to  an  earlier  stage  in  the  development 
phase.  In  some  cases,  crossing  back 
into  the  conceptual  phase  might  be 
necessary. 

For  the  most  part,  the  change  phi¬ 
losophy  is  to  use  existing  technology 
as  much  as  possible.  This  includes 
not  only  the  SSF  technology  but  also 
the  existing  DoD  technology,  and 
Russian  Space  Station  Mir.  For  ex¬ 
ample,  propulsion,  navigation  guid¬ 
ance,  and  control  for  the  restructured 
space  station  might  come  from  a  sat¬ 
ellite  bus  built  for  a  DoD  program  or 
may  come  from  the  Russian  "space 
tug”  Salyut  FGB. 

Compared  with  the  old  Phase  C 
organization  in  Figure  5,  the  proposed 
restructured  organization  does  not 
have  Levels  I,  II  and  III.  These  offices 
merge  into  a  single  program  office 
located  at  the  Johnson  Space  Center 
which  becomes  the  lead  center.  One 


FIGURV.  4.  SSFP  F*hasc  C  Organization  Prior  to 
Restructuring. 
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of  the  original  three  prime  contractors 
is  now  the  prime  integrating  contrac¬ 
tor.  This  contractor  is  responsible  for 
making  design  changes;  finishing  up 
the  CDRs;  managing  Phase  D  involv¬ 
ing  fabrication,  integration,  test  and 
certification:  and  assisting  in  the 
preparations  for  Phases  E  and  F.  The 
new  NASA  organization  emphasizes 
preoperations  activities  such  as 
launches,  stage  assemblies,  logistics, 
science  and  on-orbit  operations. 

The  difference  between  the  mili¬ 
tary  and  NASA  at  this  point  is  that,  in 
the  military,  the  receiving  organiza¬ 
tion  might  have  the  right  to  refuse 
transition  of  a  development  program. 
In  this  case,  the  new  receiving  organi¬ 
zation  takes  on  an  incomplete  design 
package  with  the  intent  of  streamlin¬ 
ing  the  entire  activity. 

The  streamlining  effort  is  seeking 
greater  management  efficiencies.  The 
PM,  for  example,  will  have  greater 
budget  authority  and  control  over 
contracts  by  managing  out  of  one 
program  office.  His  key  managers  will 
report  to  him  and  not  to  the  center 
directors  as  in  the  past.  The  new  man¬ 
agement  approach  includes 
multidisciplinary  integrated  product 
teams,  which  have  been  used  suc¬ 
cessfully  in  the  military.  The  idea  is  to 
bring  together  players  responsible  for 
a  given  product  or  area.  For  example, 
design  engineering,  manufacturing, 
operations,  safety,  science  and  utili¬ 
zation  would  be  on  a  team  that  has 
buc^t,  schedule  and  technical  area 
of  responsibility.  The  teams  will 
include  NASA  and  contractor 
personnel. 

The  new  program  office  is  expected 
to  have  a  core  of  300  NASA  personnel 
and  be  supported  by  approximately 
700  matrixed  personnel. 

Summary 

The  SSFP  is  a  major  national  tech¬ 
nical  program  that  provides  some  in¬ 
teresting  technical  and  management 
comparisons  with  major  military  sys¬ 
tems.  For  instance,  the  submarine 


has  technical  similarities  in  environ¬ 
mental  control  for  long  duration  mis¬ 
sions  that  have  benefitted  the  SSFP  in 
information  exchanges.  The  manage¬ 
ment  of  a  submarine  program  differs 
from  a  space  station  program.  Sub¬ 
marines  are  developed  and  built  by 
modifying  previous  designs.  Construc¬ 
tion  is  done  in  a  shipyard  on  earth, 
whereas  SSF  is  a  completely  new  de¬ 
sign  assembled  in  space  with  pieces 
arriving  over  a  period  of  several 
launches. 

The  SDI  has  some  interesting  tech¬ 
nical  exchange  opportunities  in  the 
areas  of  maintenance  in  space  using 
robotics  and  manned  extravehicular 
activities.  Some  striking  similarities 
exist  between  the  SDI  and  SSFP  in 
managing  a  major  program  with  a 
large  budget. 

The  PM  is  in  a  public  scrutiny 
“fishbowl,"  and  under  pressure  from 
groups  wanting  to  take  the  money 
away  or  receive  a  bigger  piece  of  the 
program.  The  PM  must  engage  in 
public  debate  with  caution  and  with¬ 
out  lobbying.  He  must  be  able  to 
utilize  consultants  and  outside  ex¬ 
perts  effectively,  and  recognize  the 
difference  between  those  who  will  be 
on  his  side  and  those  who  might  harm 
him  or  his  program.  He  must  recog¬ 
nize  and  deal  effectively  with  those 
who  have  special  interests  and  those 
whose  political  strength  may  be  greater 
than  their  capabilities  to  carry  out  the 
program.  Finally,  he  must  provide 
Congress  and  the  President  with  clear 
status  information  and  be  trustworthy. 

The  program  life-cycle  phases  of 
NASA  and  the  military  closely  re¬ 
semble  one  another.  The  NASA  life 
cycle  is  tailored  ultimately  to  launch¬ 
ing  something  into  space,  whereas 
the  military  life  cycle  is  geared  to  a 
variety  of  weapon  systems  and 
products. 

In  SSFP  software  development, 
DoD-STD-2167A  provides  support¬ 
ing  and  bacl^ound  information  but 
program  requirements  are  based  on 


N/\SA  experience.  The  NASA  and  the 
military  develop  hardware  and  soft¬ 
ware  in  parallel,  but  SSFP  staggers  its 
software  reviews  after  the  hardware 
reviews. 

Organizational  changes  are  a  nec¬ 
essary  part  to  keep  a  program  in  trim 
and  to  effectively  meet  new  problems 
that  emerge  in  the  changing  program 
phases.  The  space  station  organiza¬ 
tion  in  the  Conceptual  Studies  Phase 
(A),  like  in  the  military,  was  small. 

In  the  Definition  Phase  (B).  the 
space  station  organization  became 
larger  but,  unlike  the  military,  it  was 
decentralized  with  different  NASA 
centers  directing  the  definition  con¬ 
tracts. 

In  the  Development  Phase  (C),  like 
the  military,  a  much  larger  organiza¬ 
tion  had  to  be  established  to  meet  the 
design  detail  that  ultimately  had  to  be 
produced  before  being  manufactured. 
Unlike  the  military,  a  decentralized 
pattern  of  organization  continued  with 
a  three-tier  program  management 
structure  put  into  place. 

The  SSFP  is  being  restructured  with 
a  new  program  management  organi¬ 
zation  that  is  more  centralized  and 
has  product  team  concepts  used  by 
the  military. 

The  SSFP  has  a  new  name.  Inter¬ 
national  Space  Station  Alpha,  and  a 
new  configuration.  The  comparisons 
made  herein,  however,  are  useful 
since,  by  understanding  how  major 
programs  change  and  evolve,  better 
programs  can  be  built  in  the  future. 


Endnotes 
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EXPANDING  HORIZONS 


AGGRESSIVE  AND 
ENTHUSIASTIC  SOFTWARE 
ENGINEERING 

No  Longer  "Just  Writing  Code" 


e  brochure  distributed  by  The 
United  States  Army  Information 
Systems  Software  Development 
Center  -  Washington  (SDC-W) 
states  that  SDC-W  has  been  the  leader 
for  the  past  30  years  in  planning, 
designing,  testing,  implementing  and 
maintaining  the  Standard  Army  Man¬ 
agement  Information  Systems 
(STAMIS).' 

However,  at  times,  in  many  large 
organizations  responsible  for  the  de¬ 
velopment  of  computer  software,  the 
emphasis  mistakenly  is  placed  on  the 
implementing  stage  of  software  de¬ 
velopment.  This  is  an  understand¬ 
able  mistake  because  this  is  the  phase 
of  software  development  when  a  tan- 


LTC  Larry  G.  Baker,  USA 

gible  product  (software  code)  is  pro¬ 
duced,  and  this  is  the  commodity  de¬ 
sired  by  the  customer.  However,  this 
mistake  can  be  costly  in  light  of  the 
fact  that  more  than  70  percent  of  the 
software  cost  is  for  software  mainte¬ 
nance  (correcting  the  initial  software 
code). 

The  answer  to  the  problem  of  “just 
writing  code”  is  an  aggressive  and 
enthusiastic  application  of  software 
engineering. 

What  Is  Software 
Engineering? 

A  software  engineer  is  one  who 
applies  a  disciplined  engineering  ap¬ 
proach  to  software  development.  The 


software  engineer  must  be  concerned 
with  more  than  the  software  solution 
to  the  project.  Most  often,  the  engi¬ 
neering  side  of  the  sofuvare  engineer 
is  forgotten,  and  this  can  be  costly  in 
terms  of  dollars  and  time.  Understand¬ 
ing  engineering  is  more  important  than 
understanding  coding.  That  is,  soft¬ 
ware  engineers  are  engineers  first  and 
builders  of  software  second;  they  ap¬ 
ply  engineering  concepts  to  their 
work.- 

The  software  engineering  concept 
is  a  fairly  new  discipline.  In  the  early 
times  of  software  development,  the 
code  was  fairly  simple,  and  could  be 
handled  easily  by  one  or  rwo  people. 
As  the  size  and  complexity  of  the 
softw'are  projects  grew,  the  people  who 
developed  the  earlier  projects  were 
involved  again  on  these  more  com¬ 
plex  projects  because  they  were  suc¬ 
cessful  with  the  initial  programs.  This 
software  development  style  led  to  the 
current  cliche  of  the  “software  crisis.” 
The  fundamental  cause  of  the  soft¬ 
ware  crisis  is  that  massive,  software- 
intensive  systems  have  become 
unmanageably  complex.' 

In  addition  to  the  complexity  of 
software  development  efforts,  the 
needs  and  problems  users  present  are 
becoming  increasingly  more  perplex¬ 
ing.  To  ensure  the  software  solutions 
that  are  developed  are  useful  to  the 
customer,  software  developers  must 
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be  aware  of  user  requirements  and 
real-world  factors.  David  Marca  clas¬ 
sified  as  either  compulsive  or  serious 
programmers  the  original  software 
developers  who  performed  software 
development  as  programs  became 
more  complex. 

According  to  Marca,  four  different 
types  of  programmers  exist.  Program¬ 
mers  lacking  purpose  and  awareness 
of  real-world  factors  can  be  classified 
as  compulsive  programmers.  Program¬ 
mers  aware  of  real-world  factors  but 
with  no  goals  are  undirected  in  their 
work.  Programmers  with  a  clearly  es¬ 
tablished  purpose  are  serious  pro¬ 
grammers;  they  approach  the  com¬ 
puter  intending  to  obtain  useful 
results.  But,  serious  programmers  are 
not  software  engineers  if  they  are  not 
aware  of  real-world  factors.  Figure  1 
summarizes  these  programming  per¬ 
sonalities.^ 

The  deficiency  of  not  knowing  the 
real-world  factors  causes  the  serious 
programmer  to  create  software  that 
fails  to  meet  customer  demands.  The 
principles  of  software  engineering  at¬ 
tempt  to  bridge  this  difficult  gap  in 
building  well-engineered  software. 
This  ability  to  identify  and  assess  prac¬ 
tical,  real-world  factors  are  key  to 
software  development.  Separating 
software  engineers  from  other  pro¬ 
grammers  is  their  ability  to  make  de¬ 
cisions  with  practical  issues  in  mind 
during  all  software  development 
phases.* 

The  software  en^neer  must  take  user 
needs  and  problems  and  apply  various 
goals  (discussed  later  in  this  article) 
and  real-world  factors  to  produce  a 
software  solution  for  the  user.  To  pro¬ 
duce  the  correct  software  solution,  the 
software  engineer  must  use  an  iterative 
process  with  software  development 
cycle  to  ensure  the  programmer’s  final 
solution  is  what  the  user  really  wants. 
Only  by  applying  software  engjneeiing 
concepts  and  goals  can  the  final  prod¬ 
uct  be  useful  to  the  end  user.  Figure  2 
summarizes  inputs  and  outputs  for  the 
software  engineer.* 


The  reliability 
factor  for  software 
must  be  initiated 
early  in  its 
development, 
which  begins  with 
understanding 
user  needs. 

Software  Engineering 
Goals  and  Purposes 

Software  engineers  must  have  es¬ 
tablished  purposes  and  goals  when 
developing  software.  Purposes  and 
goals  are  the  key  ingredients  separat¬ 
ing  programmers  from  software  engi¬ 
neers.  In  general,  the  six  engineering 
goals  or  purposes  that  must  be  met  to 
ensure  the  successful  development  of 
a  computer  software  project  are;  time¬ 
liness,  efficiency,  reliability,  simplic¬ 
ity,  modifiability  and  cost-effective- 
ness.’^ 

The  software  must  be  done  in  a 
timely  manner  to  ensure  that  the  sys¬ 
tem  being  developed  is  not  obsolete 


prior  to  fielding.  Also,  if  the  software 
development  time/cycle  as  shown  in 
Figure  2  is  too  long,  then  user  require¬ 
ments  will  change  to  meet  the  new 
enwronment  in  which  they  are  work¬ 
ing.  .M  times,  the  efficiency  require¬ 
ment  is  overemphasized.  It  is  an  im¬ 
portant  goal,  but  only  in  the  context  cf 
the  system  being  developed.  If  the 
emphasis  is  to  save  one  nanosecond 
of  CPU  time,  this  efficiency  will  not  be 
realized  by  the  user,  even  in  a  real¬ 
time  system.  Often,  this  efficiency  can 
be  postponed  until  later  in  the  soft¬ 
ware  development  cycle  when  the 
entire  system  is  more  mature  and  a 
better  decision  can  be  made  regard¬ 
ing  software  efficiency. 

Reliability  is  a  crucial  goal  for  the 
software  engineer.  The  software  must 
be  developed  so  it  will  respond  cor¬ 
rectly  to  the  user’s  needs  and  problems. 
The  reliability  factor  for  software  must 
be  initiated  early  in  its  development, 
which  begins  with  understanding  user 
needs.  A  serious  problem  with  reliabil¬ 
ity  occurred  in  one  of  the  first  versions 
of  the  Ballistic  Missile  Early  Warning 
System  (BMEWS).  The  initial  version 
of  this  critical  softw'are  detected  the 
rising  of  the  moon  as  an  moving  object 
over  the  horizon  and,  according  to  the 
software  algorithms,  the  moon  was  iden¬ 
tified  as  an  unknown,  hostile  target.” 
The  software  performed  exactly  as 
requested;  the  problem  was,  as  the 
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user  described,  in  not  identifying  cor¬ 
rectly  the  criteria  for  designating  a 
“target"  as  hostile  or  friendly. 

The  user  must  be  kept  in  the  devel¬ 
opment  loop  to  ensure  the  software 
under  development  is  meeting  his 
needs.  Two  of  the  primary  goals  of 
software  engineering  —  simplicity  and 
modifiability  —  are  attributed  to  the 
user  and  his  ability  to  use  the  soft¬ 
ware.  Ease  of  use  is  a  vital  character¬ 
istic  for  any  software;  therefore,  the 
user  interface  to  the  software  must  be 
designed  carefully.  The  user  is  not 
interested  in  the  internal  workings  of 
the  software:  however,  user  interface 
can  be  one  of  the  most  critical  factors 
in  determining  the  overall  success  of 
the  system. 

This  view  of  the  overall  software 
package  is  backwards  to  the  typical 
software  developer  who  looks  prima¬ 
rily  at  the  software  from  the  internal 
workings  outward  to  the  user  inter¬ 
face.  As  the  user  becomes  more  adept 
at  using  the  system,  he  will  begin  to 
want  other  soWare  enhancements  or 
changes  to  make  his  job  even  easier. 
The  software  engineer  must  be  aware 
of  this  phenomena  and  develop  soft¬ 
ware  that  will  be  easy  to  modify  in  the 
future.  This  will  help  reduce  the  soft¬ 
ware  maintenance  cost,  which  can  be 
two-to-three  times  more  expensive 
than  the  original  cost  of  developing 
the  software. 

Government 

Standards 

Help  and  assistance  is  available 
for  the  software  engineer  in  develop¬ 
ing  software  that  meets  government 
standards.  The  most  important 
government  standard  for  providing 
guidelines  for  software  engineering  is 
DoD  Standard  2167A,  "Defense 
System  Software  Development,”  the 
principal  guide  for  developing  soft¬ 
ware  to  government  standards.  This 
document  describes  software-specific 
requirements  of  system  engineering, 
shows  how  software  fits  into  the  “big 
picture,”  and  provides  detailed 
escriptions  of  all  documents  (Data 


The  user  is  not 
interested  in  the 
internal  workings  of 
the  software: 
however,  user 
interface  can  he  one 
of  the  most  critical 
factors  in 
determining  the 
overall  success 
of  the  system. 

Item  Descriptions)  that  must  be  pro¬ 
duced  by  the  software  engineering 
team. 

The  DoD-STD-2167A  also  empha¬ 
sizes  activities  to  be  performed  during 
software  engineering,  with  the  activi¬ 
ties  oriented  more  toward  managing 
the  software-development  effort 
throughout  the  development  cycle,  as 
opposed  to  technical  approaches  to 
software  engineering.’ 

Summary 

No  longer  can  we  in  DoD  develop 
software  in  the  absence  of  the  stimuli 
from  the  user  and  other  real-world 
factors.  Computer  programmers  can¬ 
not  isolate  themselves  from  the  users, 
and  develop  software  from  an  iso¬ 
lated  point  of  view.  Only  by  applying 
the  software-engineering  principles 
can  we  hope  to  stop  or  at  least  slow 
the  “software  crisis.”  Only  by  enforc¬ 
ing  a  disciplined  engineering  approach 
on  the  software  development  can  fu¬ 
ture  computer  systems  be  developed 
that  will  meet  end-user  needs.  Only 
by  using  software  engineering  can  we 
eliminate  the  concept  of  the  “black  art 
or  wizardry  of  software  development.” 


If  we  are  to  develop  better  software 
(of  quality,  on  time,  under  budget), 
we  must  expand  our  horizons  from 
the  narrow  view  of  software  program¬ 
mers  (writing  code)  to  a  more  ex¬ 
panded  view  of  the  software  engineer. 
We  must  follow  a  disciplined  engi¬ 
neering  approach  to  develop  software. 
This  approach  is  software  engineering. 
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later  than  February  24,  1995.  Paper  will  be  evaluated  to  be  accepted  as  session  presentations  and/or  published 
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Acquisition  personnel 
entering  an  international 
acquisition  program  will 
be  confronted  with  a 
different  legal,  i 

administrative  and  / 
ethical  framework  /  y 
than  found  in  A  \ 

domestic  Jn  ^ 

programs*  v  K 


Legal  and  Administrative 
Framework 

The  Constitution  of  the  United 
States  (Article  I,  Section  9,  Clause  (8)) 
explicitly  prohibits  federal  officials 
from  accepting  any  office,  title,  gift  or 
compensation  from  a  foreign  ruler  or 
government  without  congressional 
consent.  Virtually  every  activity  of  a 
federal  official  conducted  with  for¬ 
eign  representatives  must  be  autho¬ 
rized  by  appropriate  legal  and  admin¬ 
istrative  authority  (directives, 
instructions,  regulations  and  policy 
memoranda).  Table  1  shows  some  of 
the  broad  activities  associated  with 
international  acquisition  programs. 
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and  a  general  reference.  These  are 
listed  in  the  most  probable  order  in 
which  they  would  encountered  in 
the  evolution  of  an  international  ac¬ 
quisition  program. 

General  Principles  of 
Ethical  Conduct 

“Ethical  Conduct  for  Department 
of  Defense  Personnel,”  as  contained 
in  an  Under  Secretary  of  Defense  (Ac¬ 
quisition)  Memorandum  of  Septem¬ 
ber  26,  1991,  provides  no  specific 
guidance  on  ethical  conduct  of  de¬ 
fense  acquisition  personnel  in  inter¬ 
national  situations.  Presumably,  the 
basic  ethical  principles  of  integrity, 
honesty  and  fairness  should  apply. 
However,  we  should  be  aware  that 
these  principles  may  have  different 
meaning  in  other  cultures.  This  make 
our  definitions  not  better  or  worse, 
only  different. 

For  example,  take  the  first  prin¬ 
ciple  of  integrity.  In  many  cultures, 
especially  those  which  are  religion- 
based,  the  end  does  justify  the  means. 
The  second  principle  of  honesty  can 
be  misinterpreted.  Certain  cultures, 
especially  in  the  Far  East,  place  such 
a  high  emphasis  on  politeness  and 
avoiding  offense,  that  normal  Ameri¬ 
can  candidness  could  be  found  offen¬ 
sive.  The  third  principle  of  fairness 
may  be  the  most  difficult  ethical  prin¬ 
ciple  to  uphold  in  the  international 


environment.  Fair  play  is  culturally 
American,  and  evolved  primarily  out 
of  English  culture.  It  has  no  meaning 
in  many  cultures.  Fairness,  compro¬ 
mise,  and  split-the-difference  are  very 
American.  Compromise  can  be  con¬ 
sidered  as  a  sign  of  weakness  in  some 
cultures.  Split-the-difference  may  re¬ 
ally  mean  that  you  are  now  halhvay 
closer  to  the  correct  solution  in  the 
foreigner’s  point  of  view.  One  thing  is 
certain  —  the  American  will  be  the 
most  conscious  of  the  ethical  consid¬ 
erations  in  the  program  in  a  virtual 
checklist  mentality.'^ 

Specific  Principles  of 
Ethical  Conduct 

I  conducted  a  thorough  review  of 
the  14  “Principles  of  Ethical  Conduct 
for  Government  Officers  and  Employ¬ 
ees”  from  Executive  Order  12674 
(April  12,  1989)  for  potential  interna¬ 
tional  implications.  Nothing  in  the  14 
principles  applied  sp>ecifically  to  in¬ 
ternational  acquisition  programs; 
however,  many  of  the  principles 
should  be  highlighted  for  special  in¬ 
ternational  implications.  Significantly, 
more  than  half  of  the  14  ethical  prin¬ 
ciples  have  international  implications. 
Those  principles  follow  with  a  general 
discussion  of  the  international  impli¬ 
cations.  To  the  reader,  I  point  out  that 
this  is  a  discussion  of  where  issues  are 
likely  to  arise,  not  final  legal  solutions 
to  every  possible  contingency.  The 


TABLE  I.  Aclivilies  Associated  with  International 
Acquisition  Programs 


Broad  Activities _ Legal  and  Administrative  Authorities 


Social  Events  and  Receptions 
Visits 

Exchange  of  Technical  Information 

Negotiation 

Cooperative  Acquisition 


DoD  Directive  5500.7’ 

Country  Clearance  Procedures^ 
Data  Exchange  Agreement 
Memorandum  of  Agreement* 

DoD  Instruction  2015.4® 

DoD  Directive  2000.9  -  draft® 

DoD  Directive  5230.1  P 

DoD  Directive  5530.3® 

General  R&D  Authority® 

Quayle  Authority'® 

Cooperative  R&D  Authority" 
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remaining  principles  with  no  distin¬ 
guishing  international  implications 
are  shown  for  sake  of  completeness 
in  Table  2. 

—  “Public  service  is  a  public  trust, 
requiring  employees  to  place  loyalty  to 
the  Constitution,  the  laws,  and  ethical 
principles  above  private  gain." 

Loyalty  to  the  Constitution,  and 
specifically  Article  I,  Section  9,  Clause 
(8),  prohibits  federal  officials  from 
accepting  any  office,  title,  gift  or  com¬ 
pensation  from  foreign  rulers  or  gov¬ 
ernments,  unless  authorized  by  the 
Congress. 

—  “An  employee  shall  not,  except 
pursuant  to  such  reasonable  excep¬ 
tions  as  are  provided  by  regulation, 
solicit  or  accept  any  gift  or  other  item  of 
monetary  value  from  any  person  or 
entity  seeking  official  action  from,  do¬ 
ing  business  with,  or  conducting  ac¬ 
tivities  regulated  by  the  employee’s 
agency,  or  whose  interests  may  be  sub¬ 
stantially  affected  by  the  performance 
or  nonperformance  of  the  employee’s 
duties.” 

Gifts  from  foreign  governments  are 
treated  differently  than  gifts  from  con¬ 
tractors.  Unsolicited,  promotional 
items  of  nominal  value  (not  exceed¬ 
ing  $20  p)er  item,  or  $50  per  company 
per  calendar  year)  are  generally  ac¬ 
ceptable  from  a  contractor,  domestic 
or  foreign.  An  unsolicited  gift  from  a 
foreign  ^vemment  valued  at  less  than 
$200  is  generally  acceptable  in  accor¬ 
dance  with  the  DoD  directive  on  gifts 
from  foreign  governments.'^  If  the  gift 
is  greater  than  $200  in  value,  an  at¬ 
tempt  should  be  made  to  decline  ac¬ 
cepting  it.  However,  if  this  would  re¬ 
sult  in  offense  or  embarrassment,  or 
adversely  affect  U.S.  foreign  relations, 
the  gift  may  be  accepted  on  behalf  of 
the  government.  Special  rules  apply 
in  this  instance,  but  in  general  terms, 
one  may  surrender  the  gift  to  your 
agency  for  disposal  or  official  use,  or 
the  recipient  may  purchase  it  at  the 
appraised  value  plus  appraisal  costs.''* 
The  key  word  with  regard  to  gifts  is 


The  key  word 
with  regard 
to  gifts  is 
'‘accept”  vs. 
"solicit,” 
the  latter 
always  being 
unethical  and 
illegal. 


“accept”  vs.  “solicit,”  the  latter  al¬ 
ways  being  unethical  and  illegal.  Con¬ 
sult  with  your  agency’s  legal  office  in 
this  instance,  or  wherever  a  question 
concerning  a  breach  of  ethical  con¬ 
duct  might  exist. 

—  “Employees  shall  make  no  unau¬ 
thorized  commitments  or  promises  of 
any  kind  purporting  to  bind  the  Gov¬ 
ernment.” 


Commitments  binding  the  U.S. 
Government  are  subject  to  strict  con¬ 
trols  and  much  contemporary  legal 
debate.  Control  of  international  ac¬ 
quisition  program  commitments  is 
exercised  by  the  Office  of  the  Secre¬ 
tary  of  Defense  under  DoD  Directive 
5530.3  on  international  agreements. 
One  must  obtain  proper  legal  author¬ 
ity  to  both  negotiate  and  conclude  an 
international  acquisition  program 
agreement.  This  agreement  is  normally 
called  a  Memorandum  of  Agreement 
(MOA),  or  Memorandum  of  Under¬ 
standing  (MOU),  and  is  required  by 
law  for  all  cooperative  acquisition 
programs.  The  controls  of  the  Office 
of  the  Secretary  of  Defense  on  the 
MOA/MOU  process  extend  to  deter¬ 
minations  of  appropriate  legal  au¬ 
thority  to  conduct  the  program,  finan¬ 
cial  authority  to  obligate  funds  for  the 
program,  security  policy  authority  to 
exchange  information,  and  host  of 
other  complex  considerations. 
Furthermore,  a  requirement  for 
these  agreements  is  consultation 
with  the  Departments  of  Commerce 
and  State,  as  well  as  congressional 
notification. 

—  “Employees  shall  act  impartially 
and  not  give  preferential  treatment  to 
any  private  organization  or  individual.  ” 


1time:2c$pec^  Princip^  ^fBtikieat  CmBdmct 

in 
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This  principle  requires  elaboration, 
as  it  most  often  seems  to  work  in  the 
reverse  with  international  acquisi¬ 
tions.  Certain  types  of  preferential 
treatment  for  domestic  contractors  is 
encouraged  by  the  Federal  Acquisi¬ 
tion  Regulations  to  meet  national 
objectives  of  protecting  or  enhancing 
domestic  sources  for  defense  prod¬ 
ucts.  Examples  of  this  type  of  legal 
preferential  treatment  are  the  Buy 
American  Act,  the  Berry  Amendment 
on  food  and  clothing,  the  Stratton 
Amendment  on  large  caliber  gun 
tubes,  and  Required  Sources  for  Jew¬ 
eled  Bearings.  However,  under  cer¬ 
tain  situations,  the  Secretary  of  De¬ 
fense  may  require  subcontracts  be 
awarded  to  particular  allied  nation 
subcontractors  in  furtherance  of  co¬ 
operative  projects,  and  may  waive 
most  of  the  restrictive  provisions  of 
U.S.  law. ‘5 

—  “Employees  shall  protect  and 
conserve  Federal  property  and  shall 
not  use  it  for  other  than  authorized 
activities." 

The  protection,  conservation  and 
authorized  use  of  U.S.  Government 
property  in  international  acquisition 
programs  can  become  a  complex  con¬ 
sideration.  The  treatment  of  intellec¬ 
tual  and  physical  property,  and  the 
potential  liability  associated  with  the 
use  of  government  property  within  an 
international  acquisition  program,  is 
far  beyond  the  scope  of  this  article. 
Normally,  the  U.S.  Government  must 
obtain  a  return,  or  quid  pro  quo,  (equal 
or  equitable,  depending  upon  the  le¬ 
gal  authority  cited)  to  conduct  the 
program.  Strict  rules  apply  to  the  loan, 
or  transfer,  of  U.S.  Government  prop¬ 
erty  in  an  international  program.** 
Experts  should  be  consulted  before 
committing  to  an  international  acqui¬ 
sition. 

—  “Employees  shall  not  engage  in 
outside  employment  activities,  includ¬ 
ing  seeking  or  negotiating  for  em¬ 
ployment,  that  conflict  with  official 
Government  duties  and  responsibili¬ 
ties.” 


One  must  be 
conscious  of 
national 
sovereignty, 
and  different 
rules  and 
regulations 
governing 
foreign 
nationals. 


The  Constitution  prohibits  com¬ 
pensation  to  federal  officials  for  em¬ 
ployment  with  a  foreign  government. 
However,  DoD  Directive  5500.7  on 
Standards  of  Conduct  notes  that  travel 
or  reimbursement  for  travel  may  be 
accepted  under  certain  circumstances. 
One  should  be  especially  sensitive  to 
any  aspect  of  employment  activities 
with  a  foreign  government.  Legal  coun¬ 
sel  should  be  obtained  regarding  any 
of  these  activities. 

—  “Employees  shall  disclose  waste, 
fraud,  abuse,  and  corruption  to  appro¬ 
priate  authorities.” 

Disclosure  of  waste,  fraud,  abuse 
or  corruption  must  be  made  to  appro¬ 
priate  U.S.  Government  authorities. 
One  must  be  conscious  of  national 
sovereignty,  and  different  rules  and 
regulations  governing  foreign  nation¬ 
als.  Ignoring  these  could  be  construed 
as  sanctioning  unethical  activities. 

—  “Employees  shall  adhere  to  all 
laws  and  regulations  that  provide  for 
equal  opportunity  for  all  Americans 
regardless  of  race,  color,  religion,  sex, 
national  origin,  age,  or  handicap." 


This  principle  may  become  an  is¬ 
sue  when  dealing  with  certain  cul¬ 
tures.  Gender  is  an  especially  sensi¬ 
tive  issue  in  much  of  the  world,  and 
especially  the  Middle  East  and  Far 
East  (although  this  is  country  depen¬ 
dent).  I  advise  women  entering  the 
world  of  international  acquisition  to 
study  this  issue  carefully.*'  Religion 
could  be  an  issue  in  selected  nations 
in  the  Middle  East.  My  personal  expje- 
rience  is  that  race  is  of  lesser  impor¬ 
tance;  Americans  are  perceived  and 
accepted  as  a  multiracial  society.  U.S. 
Government  officers  and  employees 
should  be  especially  vigilant  in  avoid¬ 
ing  the  compromise  of  this  ethical 
principle  in  international  situations. 

Conclusions 

International  acquisition  programs 
present  unique  ethical  and  legal  chal¬ 
lenges  to  the  acquisition  professional. 
The  acquisition  professional  should 
become  educated  on  the  foreign  cul¬ 
ture  that  he  or  she  will  be  dealing  with 
to  avoid  any  unanticipated  negative 
outcomes  from  a  clash  in  principles. 
More  important,  the  acquisition  pro¬ 
fessional  needs  to  become  familiar 
with  the  highlighted  specific  principles 
to  avoid  breaches  in  ethical  conduct 
in  international  situations  or,  most 
importantly,  to  avoid  unanticipated 
administrative  or  legal  violations.  A 
review  of  my  remarks  for  these  prin¬ 
ciples  should  serve  as  a  general  guide 
for  navigating  the  international 
minefield  of  diverse  ethical  and  legal 
standards. 


Endnotes 

1.  DoD  Directive  5500.7,  “Standards 
of  Conduct,”  May  6,  1987. 

2.  All  foreign  visits  must  be  cleared 
with  the  host  government.  Your  local 
security  office  or  international  pro¬ 
grams  office  can  advise  you  on  clear¬ 
ance  requirements  and  lead  times  for 
each  country.  NATO  visits  are  handled 
the  same  as  a  country  visit. 
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STUDIES  OF  PROGRAMS  IN  THE  PACIHC  RIM 


For  the  past  two  years,  the  Defense  Systems  Management 
College  (DSMC)  faculty  has  been  conducting  two  studies 
of  cooperative  acquisition  between  the  U.S,  Department  of 
Defense  and  the  corresponding  defense  department/agency/ 
ministry  of  selected  Pacific  Rim  (PACRIM)  nations:  Austra¬ 
lia,  Japan  and  South  Korea.  These  studies  were  conducted  to 
respond  to  a  gradually  increasing  student  demand  in  our 
international  short  courses  for  information  on  cooperative 
acquisition  with  PACRIM  nations.  The  end  result  will  be  new 
curricula  for  these  courses,  as  well  as  portions  of  a  new 
international  acquisition  guidebook. 

The  first  study  of  international  cooperative  acquisition 
was  conducted  by  Professor  Richard  Kwatnoski  of  the  Ex¬ 
ecutive  and  Short  Courses  Department.  The  research  objec¬ 
tives  were  as  follows: 

•  Describe  the  current  reality  of  cooperative  programs  in 
the  Pacific  Rim. 

•  Determine  the  prescription  for  success  by  identifying 
barriers  to,  and  facilitators  for,  cooperatii  n. 

•  Examine  similarities  and  differences  between  PACRIM 
and  NATO  Europe  programs. 

The  second  study  concentrates  on  the  comparative  de¬ 
fense  acquisition  practices  of  the  United  States  and  those  of 
Australia,  Japan  and  South  Korea.  This  effort  has  been 
conducted  by  Professor  Charles  L.  Houston  III,  recently 
transferred  to  the  Executive  and  Short  Courses  Department 
to  concentrate  on  international  activities.  This  research, 
along  with  similar  research  on  the  practices  of  selected 
NATO  nations,  will  be  used  as  new  curricula  for  our  interna¬ 
tional  courses,  as  well  as  a  new  DSMC  Press  guidebook. 
Some  of  the  key  comparative  acquisition  areas  are: 


from  left:  Or.  Yoshio  Ohyumi;  Lt  Col  (Sel)  Charles  L  Houston 
III,  USAF  (DSMC);  Mr.  Hiroyufei  Kitamura,  Japanese  Project  Of¬ 
ficer;  Mr.  Richard  Kwatnoski  (DSMC);  and  Mr.  Yukio  Miyata,  Ja¬ 
pan  Defense  Agency,  Technical  Research  and  Development  Insti¬ 
tute,  Tokyo,  Japan. 


t  •  Legislative  Oversight 

5  •  Acquisition  Agencies 

f  •  Major  Weapon  System  Criteria 

/  •  International  Arms  Sales 

•  Acquisition  Education 
)  •  Defense  Industrial  Base 

r  •  Acquisition  Process 

i  •  Planning,  Programming  and  Budgeting  System. 

/  The  capstone  of  the  research  was  a  two-week  trip, 
sponsored  by  the  Army  and  Air  Force  Directors  of  Inter¬ 
national  Cooperation/Programs,  around  the  Pacific  Rim 
1  during  May  1994.  The  journey  began  in  Seoul,  South 
Korea,  where  DSMC  researchers  met  with  the  Joint  U.S. 
Military  Affairs  Group  -  Korea  (JUSMAG-K),  From  there, 
the  researchers  went  to  the  Korean  Agency  for  Defense 
Development,  Naval  Systems  Research  and  Develop- 
\  ment  (R&D)  Center  in  Chinhae  to  discuss  the  Coastal 
Harbor  Defense  Project.  The  next  Korean  visit  was  to  the 
Agency  for  Defense  Development,  Ground  Systems  R&D 
I  Center  in  Taejon  to  discuss  the  Ammunition  Storage 
Technology  Project. 

I  The  next  stop  on  the  PACRIM  journey  was  Tokyo, 
Japan,  to  meet  with  the  U.S.  Mutual  Defense  Assistance 
Office  (MDAO  -  Japan).  All  discussions  were  conducted 
in  Tokyo  at  the  Technical  Research  and  Development 
f  Institute  of  the  Japan  Defense  Agency.  Discussions  with 
i  Japanese  government  officials  were  held  on  the  Ducted 
t  Rocket  Engine  Project  and  the  Next  Generation  Support 
t  Fighter,  more  commonly  called  FS-X. 

i  The  final  stop  was  Canberra,  Australia.  As  in  Japan,  all 
-  discussions  were  held  in  the  national  capital.  The  first 
discussions  held  were  with  the  management  of  the  Jindalee 
Operational  Radar  Network  (JORN)  Program  on  the  Ra¬ 
dar  Activities  Project.  Next,  discussions  were  held  with 
management  officials  of  the  Nulka  Project,  or  the  MK-53 
c  Off-Board  Active  Decoy  as  it  will  be  renamed  in  develop- 
«  ment  and  production.  Final  discussions  were  with  the 
£  Australian  Army’s  Director  of  Survey  regarding  the  Digital 
^  Chart  of  the  World  Project. 

§  With  data  gathering  complete,  the  tasks  of  analyzing 
13  and  publishing  the  PACRIM  research  data  remain.  Watch 
"S  for  more  on  this  in  future  issues  of  Program  Manager. 

3  A  high-level  summary  of  the  PACRIM  research  was 
«  presented  by  Professor  Kwatnoski  during  the  Common 
o  Defense  (ComDef  ’94)  Forum  in  Crystal  City  in  May. 
0-  Students  attending  the  DSMC  international  courses  will 
see  the  results,  in  detail,  during  the  special  back-to-back 
PACRIM  offerings  of  the  Multinational  Program  Manage¬ 
ment  Course  and  the  Advanced  International  Manage¬ 
ment  Workshop  planned  for  the  last  week  of  March  and 
the  first  week  of  April  1995. 
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AVOID  PITFALLS 


TEN  SURE-FIRE  WAYS  TO 
CREATE  PENTAGON 
PROBLEMS 


A  Humorous  Look  at  Maintaining  a  Good  PLG> 

S  ta  ff-  P  E  i\  /  R  c  I  a  t  io ;  ?  5  h  i  p 

Lt  Col  Bud  Vazquez,  USAF  •  Lt  Col  Greg  Lockhart,  USAF 


(ptablishing  the  Program  Executive 
I  Officer  (PEO)  structure  in  1986 
I  to  streamline  the  acquisition 
I  system  program  director  report¬ 
ing  chain  touched  off  a  firestorm  of 
debate  that  is  still  simmering.  None¬ 
theless.  Air  Staff  and  PEO  action  of¬ 
ficers  (AOs)  must  concern  themselves 
less  with  structure  and  more  with 
making  structure  work. 


Few  commentaries  exist 
on  the  PEO  staff-Program  El¬ 
ement  Monitor  (PEM)  rela¬ 
tionship.  Thus,  this  article  j 

points  out  ways  to  refresh  the  I 

rapport  needed  to  make  any  * 

team  relationship  work  effec¬ 
tively  by  highlighting  sure-fire 
ways  to  problems.  We  begin 
with  a  brief  description  of  the 
relationship.  The  USAF  PEOs  are 


Lt  Col  Vazquez  is  the  Director,  Air¬ 
lift  Systems,  for  the  Program  Executive 


1 .  Be  Ri«;id 

2.  Don’t  trust 


Officer  for  Tactical  and  Airlift  Programs, 
the  Pentagon.  Lt  Col  Lockhart  is  the 
lead  C-1 7  Program  Element  Monitor  in 
the  Air  Force  Secretariat’s  Directorate 
of  Long-Range  Power  Projection.  SOF, 
Airlift,  and  Training  Programs.  Assis¬ 
tant  Secretary  for  Acquisition,  the  Pen¬ 
tagon. 


responsible  for  program  execution. 
while  the  PEM’s  boss,  the  Mission 
Area  Director  (MAD),  is  responsible 
for  representing  the  program  to 
the  Air  Staff,  the  Office  of  the  Secre¬ 
tary  of  Defense  (OSD)  staff,  and  to 
Congress. 


In  theory,  this  means  that  the  PEO 
works  issues  affecting  day-to-day 
management  of  a  program  —  cost, 
schedule,  supportability  and  perfor¬ 
mance.  The  PEOs  were  established 
for  three  reasons:  to  provide  a  direct 
and  streamlined  chain  of  command 
to  the  Ser\'ice  acquisition  execu¬ 
tive.  to  keep  the  program  di¬ 
rector  informed  of  develop¬ 
ments  "inside  the  beltway." 
and  to  free  program  directors 
from  frequent  trips  to  Wash¬ 
ington  so  they  can  manage 
the  program. 

On  the  other  hand,  the 
MAD  is  responsible  for  coor¬ 
dinating  all  aspects  of  the  pro¬ 
gram  with  those  outside  the 
execution  chain  —  funding, 
congressional  reporting  and  re¬ 
sponses.  staff  coordination,  and  the 
like.  However,  we  nil  recognize  there 
is  no  clean  break  of  responsibilities. 
To  start  our  humorous  journey,  we 
can  examine  some  of  the  many  inter¬ 
pretations  of  the  roles  in  Figure  1. 

It  is  easy  to  see  how  these  different 
perspectives  would  affect  how  one 
treated  the  relationship.  Not  surpris¬ 
ingly.  we  propose  to  use  our  version  of 
the  truth  —  that  wh'ch  would 
emphasize  teamwork  —  to  move  into 
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the  meat  of  the  ten  sure-fire  ways 
to  disaster. 

How  could  you  ensure 
strife,  argument  and  disas- 

ter  in  the  environment  of  _ 

overlapping  responsibili¬ 
ties?  Here  are  our  thoughts, 
broadly  lumped  into  three 
categories  —  Roles  and 
Missions,  Interpersonal 
Skills,  and  Professional 
Courtesy. 

I.  Roles  and 
Missions 

—  Sure-Fire  Way  to 
Problems  #1:  BE  RIGID. 

Make  sure  you  view  roles  and 
missions  as  inviolate  with  no 
possibility  for  crossover.  For  added 
disastrous  results,  apply  this  rule  ev¬ 
ery  time  you’re  on  leave  or  temporary 
duty.  Ensure  the  program  office  fears 
crossing  the  lines  you've  drawn,  too. 

—  Sure-Fire  Way  to  Problems  #2: 
DON'T  TRUST.  Too  much  trust  can 
be  trouble  for  an  AO.  First  and  fore¬ 
most.  make  sure  you  don’t  trust  the 
way  the  system  is  set  up.  Be  confident 
that  you’re  the  smartest  player  around, 
and  there’s  no  way  the  PEO-PEM 
relationship  could  possibly  work.  This 
will  keep  expectations  low.  Also,  don’t 


3.  Take  things 
personally 
4.  Limit  personal 

interaction 


trust  your  counterpart  individually. 
This  way  you  are  sure  to  limit  your 
vulnerability  for  the  other  guy’s  mis¬ 
takes.  You  get  an  added  benefit  of 
simplifying  your  life  since  lack  of  trust 
is  contagious.  You’ll  never  have  to 


FIGURE  I  .PEM  !  PEO  Relationships 


APEMView 

“Who  needs  the  PEO  staff?" 


A  Center  Commander  View 
“Why  do  I  need  both?" 


A  PEO  Staff  View 
“Who  needs  the  PEMs?" 


It  is  our  first-hand  experience  and  belief  that  the  real  relationship  looks  like  the  following; 

“The  Truth" 


worry  about  his  thinking  of  you!  The 
real  pro  makes  sure  he  frequently  and 
publicly  "bad-mouths"  the  system  and 
his  counterpart  so  everyone 
knows  where  he  stands.  It's 

_  especially  effective  if  you 

can  convince  your  boss 
"they  can’t  be  trusted." 
That  way  you  can  stymie 
action  almost  every  time. 

II.  Interpersonal 
Skills 

—  Sure-Fire  Way  to 
Problems  #3;  TAKE 
THINGS  PERSONALLY. 
Even  in  the  fast-paced 
world  of  Pentagon  AOs, 
make  sure  you’re  not  very  understand¬ 
ing,  and  that  you  interpret  every  over¬ 
sight,  statement  or  action  as  aimed  at 
making  you  look  bad  or  limiting  your 
promotion  opportunity.  For  extra- 
added  effect,  pick  at  the  scabs  from 
the  occasional  "broken  glass”  in  or¬ 
der  to  undermine  any  trust  you  might 
have  (see  Sure-Fire  Problem  #2) 

—  Sure-Fire  Way  to  Problems  #4; 
LIMIT  PERSONAL  INTERACTION. 
It’s  easier  to  fail  if  you  avoid  any 
contact  with  “the  enemy.”  Faxes  work 
great  for  this.  Limit  phone  calls  to 
your  counterpart,  and  prefer  to  leave 
messages,  making  "them”  call  you. 
An  occasional  walk  to  the  other  guy’s 
office  is  bad  judgment,  so  is 
carpooling,  and  going  to  lunch  to¬ 
gether.  These  heinous  actions  are 
only  exceeded  by  socializing  with 
your  opposite  number  off  duty.  Treat 
personal  interaction  as  you  would 
fraternization  —  be  discreet. 

—  Sure-Fire  Way  to  Problems  #5: 
BE  HUMORLESS.  Humor  can  make 
the  Pentagon  tolerable,  if  not  enjoy¬ 
able,  so  avoid  it  like  the  plague.  A 
serious  countenance  will  ensure  you 
are  taken  seriously.  If  you  must 


show  emotion,  it  is  much  better  to  get 
angry. 

—  Sure-Fire  Way  to  Problems  #6. 
BE  UNRELIABLE.  Reliability  is  as¬ 
sociated  with  predictability  and,  like 
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A 


5.  Be  humorless 

6.  Be  unreliable 


a  fighter  pilot,  “jinking”  makes  you  a 
much  tougher  target  to  hit. 
Therefore,  when  you  say 
you’ll  do  something,  try  not 
to  do  it.  Bust  suspenses,  don’t 
return  phone  calls,  and  con¬ 
stantly  revisit  closed  issues. 

Best  of  all,  deny  you  ever  made 
the  commitments  in  the  first 
place  (reference  Sure-Fire 
Problem  #2). 

III.  Professional  Courtesy 

—  Sure-Fire  Way  to  Problems  #7: 
“HOG”  INFO.  It  is  very  effective  to 
take  a  parochial  view  of  who  needs 
what  information.  Assume  you  can 
infallibly  predict  who  will  need  what 
information  and  husband  it  accord¬ 
ingly.  Never,  ever  send  information 
that  might  help  your  counterpart  look 
good  if  you  can  help  it.  For  extra  style, 
when  the  other  person  asks  for  infor¬ 
mation  you  don’t  think  he  needs,  tell 
him  you’ve  never  seen  it!  Religiously 
avoid  the  practice  of  sending  courtesy 
copies.  Practice  good  OPSEC/ 
COMSEC. 

—  Sure-Fire  Way  to  Problems  #8: 
ENSURE  SHORT  NOTICE.  Alas,  some 
exercise  will  inevitably  force  you  to 
interact  to  obtain  coordination  —  a 
meeting,  a  document  or  a  boss.  Train 


yourself  to  think  of  your  counterpart 
only  at  the  last  minute  (after  5:30  p.m. 
is  best).  Then  fax  a  curt  note  saying 
“need  your  comments”  within  a  half- 
hour  of  the  suspense.  The  real  pro  will 
backdate  the  note  to  make  it  look  like 
you  gave  more  time  than  in  reality. 
Give  yourself  extra  points  when 
you  tell  your  boss  "I  gave  it  to 
them  yesterday  and  they  have 
not  responded.” 

—  Sure-Fire  Way  to  Problems 
#9:  DON'T  BACKFILL.  On  those 
occasions  when  you  attend  meet¬ 
ings  or  listen  in  on  conference 
calls,  try  not  to  slip  up  and  tell  the 
other  person  about  it.  Backfilling  cre- 


“The  meeting?  What  meeting?  Oh, 
the  OSD  meeting.  Why  didn’t  you  say 
that?,”  for  maximum  effect.  C>eny  ever 
being  told  of  meetings  or  suspenses  if 
you  forgot  or  were  overwhelmed  by 
another  action.  This  way  you  can 
further  foster  the  feelings  in  your  or¬ 
ganization  that  the  "other  side”  al¬ 
ways  ignores  you. 

Conclusion 

While  we  attempted  to  use  humor 
and  a  bit  of  the  absurd  to  make  a 
point,  unfortunately,  these  descrip¬ 
tions  are  closer  to  the  mark  than  we 
would  like.  Too  many  critical  partner¬ 
ships  inside  the  Pentagon  are  poi¬ 
soned  by  some  of  these  sure-fire  ways 
to  problems.  With  a  little  discipline, 
common  sense  and  courtesy, 
AOs  can,  and  must,  avoid  these 


pitfalls. 


^  We  hope  this  trip  through  a 
^  fictitious  PEO-PEM  action  of¬ 
ficer  partnership  does  not  ring  too 
true  for  you,  and  may  serv'e  as  a 
helpful  reminder  on  improving  any 
team  or  partnership.  We  believe  it  is 
not  only  possible  to  have  a  good  PEO 
staff-PEM  relationship,  but  that  the 
mission  requires  it. 


7.  Hog  info 

8.  Knsiirc  shoi'l 
notice 


ates  expectations  of  trust  and 
teamwork,  and  could  provide  that  bit 
of  information  to  give  “the  competi¬ 
tion”  an  advantage  in  the  battle 
over  who’s  in  charge  of  the  program  ' 
and,  ultimately,  who  gets  promoted. 
Remember,  this  is  war!  « 


//. 


—  Sure-Fire  Way  to  Problems  | 
#10:  QUIBBLE.  A  good  technique  on  ' 
the  road  to  disaster  is  to  be  excruciat¬ 
ingly  literal.  For  example,  when  your 
opposite  number  says,  “I  thought  you 
said  you  didn’t  have  that  informa¬ 
tion!,”  responses  like  “You  asked  for 
information,  not  this  document,”  are 
very  effective.  Practice  phrases  like. 


HofiT 
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GENERAL  YATES  TELLS  PMC  94-1 
WE  MUST  NOT  LOSE  OUR  COMBAT  EDGE 


Bul.  Chanijcs  Cun  !\rsu!i  m  / 


fare  going  through  some  of  the 
most  significant  changes  in  our 
history,  changes  that  are  forc¬ 
ing  us  to  take  a  hard  look  at 
how  we  do  business  throughout  the 
defense  industrial  base.. .especially  in 
the  areas  of  acquisition  and  logis¬ 
tics.” 

The  speaker  was  General  Ronald 
\V.  Yates,  USAF,  Commander,  Air 
Force  Materiel  Command,  Wright- 
Patterson  AFB,  Ohio,  who  addressed 
students  of  the  Defense  Systems  Man¬ 
agement  College  Program  Manage¬ 
ment  Course  (PMC)  94-1  at  its  recent 
graduation. 

Citing  the  end  of  the  Cold  War  and 
the  cutback  on  defense  spending. 
General  Yates  said  the  post-Cold  War 
“still  Is  a  dangerous  place.. ..And,  as 
our  mission  changes  to  adapt  to  new 
world  realities,  our  operational  forces 
are  still  very  busy."  He  cited  our  con¬ 
tinuing  or  potential  involvement  in 
the  Persian  Gulf  and  Somalia,  Rwanda 
and  Bosnia. 

Reduction  in  defense  spending 
combined  with  the  uncertainty  in  the 
world  and  high  tempo  of  operations 
pose  “significant  challenges  for  our 
acquisition  corps.”  General  Yates 
stressed  that  reducing  costs  is  an  over¬ 
riding  concern,  and  is  “one  of  the 
fundamental  changes  sweeping 


Mrs.  Farria  is  Managing  Editor  of 
Program  Manager,  Defense  Systems 
Management  College. 


Esther  M.  Farria 


General  Yates  addresses  PMC  ^4-1  gradu¬ 
ates  at  DSMC. 


through  the  entire  defense  world. 
During  the  Cold  War  we  were  always 
asked  to  deliver  performance  and 
schedule.  Now  the  single  most  impor¬ 
tant  driving  factor  is  efficiency,”  he 
said. 

Reducing  costs  must  not  mean  we 
“lose  our  combat  edge,”  the  General 
went  on  to  say.  We  must  look  to  "high 
technology  to  help  us  achieve  effi¬ 
ciencies  across  the  board  in  the  ac¬ 
quisition  and  sustainment  business 
and  at  the  same  time  maintain  our 
military  cabilities.”  In  the  past  “our 
military  has  relied  on  advanced  tech¬ 
nology.  We  have  led  the  world  in 
technical  innovation  and  spin-offs 
from  our  efforts  have  been  a  driving 
force  in  the  civilian  world  too.” 

He  remarked  that  the  ways  we  de¬ 
velop  and  use  technology  are  chang¬ 
ing,  the  race  to  produce  new  systems 


has  slowed,  and  much  of  our  empha¬ 
sis  will  be  on  moving  advanced  tech¬ 
nology-  into  existing  systems  to  in¬ 
crease  capabilities  and  boost  system 
reliability.  “In  fact,  boosting  reliabil¬ 
ity  is  one  of  the  most  important  ways 
of  cutting  costs  while  improving  our 
operational  capability,”  he  stated:  "as 
part  of  our  effort  to  reform  and  stream¬ 
line  the  acquisition  process,  we  must 
increasingly  adapt  commercial  tech¬ 
nologies  for  military  use.” 

General  Yates  told  the  class  that 
“to  reform  and  streamline  the  acquisi¬ 
tion  process,  we  must  increasingly 
adapt  commercial  technologies  for 
military  use...dual-use  technology'  will 
become  more  important.”  He  believ'es 
we’re  going  to  need  to  make  greater 
use  of  commercial  products,  buy  more 
off-the-shelf  technology,  and  reduce 
military  specific  requirements  where 
possible.  He  further  commented: 

•  Teamwork  is  more  important  now 
than  ever.  Each  Service  is  “straining 
to  keep  their  forces  modern  and 
ready.. .budgetary  pressures  can  rip 
us  apart,  or  we  can  all  work  together 
to  ensure  that  as  a  united  American 
fighting  force  we  emerge  stronger.” 

•  “Another  way  we  need  to  achieve 
efficiencies  in  the  acquisition  and 
sustainment  business  is  through  inte¬ 
grated  product  development."  Rely¬ 
ing  on  teams  which  focus  on  the  cus¬ 
tomer  and  include  operators, 
maintainers  and  industry'  as  part  of 
the  acquisition  process  represents  a 
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major  culture  shift.  “Instead  of  devel¬ 
oping  narrow  specialists,  we’re  [Air 
Force  Materiel  Command]  focusing 
on  developing  people  who  are  able  to 
operate  we!  i,  and  lead,  these  mul¬ 
tifunctional  teams.” 

•  Don’t  just  organize;  ask  people 
for  their  ideas.  Many  hesitate  to  do 
this  because  someone  might  have  a 
substantive  idea  that  could  cause 
changes,  and  changes  can  be  disrup¬ 
tive.  More  often  than  not,  changes 
result  in  improvements. 

•  Included  in  other  innovative  ap¬ 
proaches  being  pursued  are  lean  pro¬ 
duction  and  lean  logistics,  ”to  ensure 
we  can  continue  to  field  and  support 
the  best  technology  at  a  cost  our  na¬ 
tion  can  afford. 

•  Leadership  remains  the  constant 
in  the  requirement  for  military  suc¬ 
cess.  Having  learned  lot  about  the 
mechanics  of  what  a  program  man¬ 
ager  needs  to  know,  head  into  the  real 
world  to  do  real  work.  When  you  get 
there,  you  should  have  the  technical 
preparation  you  need  to  succeed.” 

•  The  challenge  to  graduates  is  to 
be  leaders,  to  be  decisive  and  willing 
to  take  risks,  to  handle  adversity  with 
honesty  and  integrity.  Gather  a  rea¬ 
sonable  amount  of  data  and  make  a 
decision,  right  or  wrong.  Wrong  deci¬ 
sions  can  be  corrected. 

•  Be  realistic  with  cost  and  sched¬ 
ule  estimates.  D-Day  was  a  triumph 
of  American  acquisition,  logistics  and. 
more  importantly,  its  triumph  of  lead¬ 
ership,  not  just  at  the  top,  but  through¬ 
out  the  ranks.  Data  gathered  from 
history  can  help  project  the  future. 


DSMC  ELECTRONIC  CAMPUS  UPDATE 


ACQUISITION  REVIEW 

QUARTERLY 

NOW  ON  INTERNET 

DSMC  Upgrade.^  F.-Muil 
Capahilily 


n  june,  the  Defense  Systems  Man¬ 
agement  College  (DSMC)  com¬ 
pleted  the  first  phase  of  a  major 
.  program  to  upgrade  its  automa¬ 
tion  facilities.  All  staff  and  faculty  are 
now  connected  to  a  new  network  on 
campus  and  all  have  e-mail  access  to 
the  Defense  Data  Network  (DDN) 
and  Internet. 

The  Internet  e-mail  addresses 
at  DSMC  are  of  the  form  user- 
name@dsmc.dsm.mil.  where  user- 
name  is  normally  a  person’s  last  name 
and  first  initial.  Figure  1  lists  some 
well-known  e-mail  addresses  at  DSMC 
which  you  may  find  useful. 

The  DSMC  Internet  host  computer 
now  has  the  ability  to  send  and  re¬ 
ceive  public  files  using  the  Internet 
file  transfer  protocol  (ftp).  The  user 
may  ftp  to  dsmc.dsm.mil  (IP  address 
198.97.207.254)  and  logon  as  “anony¬ 
mous”  with  the  password  “guest.” 
After  logon,  the  user  should  ftp  the 
README  file  to  get  the  current  infor¬ 
mation  concerning  file  transfers. 

One  series  of  files  now  available  is 
the  Acquisition  Review  Quarterly 
(ARQ),  Volume  1,  Number  1,  Winter 
1994.  To  ftp  the  ARQ,  change  the 
DSMCPRESS  directory,  change  to  the 


REVIEW  1  / 

directory  and  ftn 
the  README.ARQfiie  for  fur¬ 
ther  information.  The  ARQ  files  are 
temporarily  in  Ventura  Publisher  for¬ 
mat,  so  the  user  will  need  this  soft¬ 
ware  to  use  the  files. 

We  are  finalizing  arrangements  to 
make  Program  Manager  available  on 
Internet. 

If  you  have  acquisition-related 
files  that  you  wish  to  share  with 
others,  you  can  ftp  them  to  the 
UPLOADS  director^'.  After  uploading 
the  files  send  an  e-mail  to 
sysop@dsmc.dsm.mil  requesting  the 
files  be  moved  from  the  UPLOADS 
directory  to  a  public  area. 

Additional  DSMC  services  and 
publications  are  planned  for  Internet 
access,  including  access  to  Program 
Manager.  A  bulletin  board  system  that 
will  include  e-mail  and  file  transfers, 
the  Program  Manager’s  Notebook 
on-line,  and  dial-in  telephone  ser\'ice 
are  some  of  the  capabilities  in 
the  works.  The  DSMC  point  of  con¬ 
tact  is  LTC(P)  Bert  Garcia.  USA, 
garcla@dsmc.dsm.mil,  or  (703)  805- 
3462. 


General  Yates  ended  by  saying  that 
the  challenges  of  today  “still  call  for 
bold  leadership,  decisiveness  and  risk 
taking.”  His  wish  for  the  graduates  is 
“the  greatest  success  for  each  of  you. 
Success  in  helping  provide  our  nation 
with  the  equipment  and  with  the  lead¬ 
ership  we  need  to  keep  America 
strong.” 


FIGURE  1.  Well-Known  E-Mail  Addresses  at  DSMC 

coinmandant@dmsc.dsm.mil . Commandant 

dsmcaa@dsmc.dsm.mil . DSMC  Alumni  Association 

dsmcpress@dsmc.dsm.mil . DSMC  Press 

library@dsmc.dsm.mil . Acker  Library 

registrar@dsmc.dsm.mil . . Registrar 

sysop@dsmc.dsm.mil . Systems  Operator 
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REENGINEERING  THE  CORPORATION 
A  Manifesto  for  Business  Revolution 

HarperBusiness,  A  Division  of  Harper  Collins  Publishers 

by  Michael  Hammer  and  James  Champy 


In  Reengineering  the  Corporation,  A 
Manifesto  for  Business  Revolution, 
the  authors  offer  strong  medicine, 
“Forget  what  you  know  about  how 
business  should  work  —  most  of  it  is 
wrong!”  Their  223-page  book  on  or¬ 
ganizational  change,  published  in 
1993,  provides  supporting  theory  and 
real-life  examples  to  support  their 
claim.  Reengineering  is  to  total  qual¬ 
ity  what  total  quality  was  to  tradi¬ 
tional  management.  To  implement 
total  quality,  you  must  successively 
document,  measure  and  incremen¬ 
tally  improve  a  process. 

Hammer  and  Champy  point  out 
two  weaknesses  of  this  approach. 
First,  if  processes  in  an  organization 
are  individually  documented  and  im¬ 
proved,  this  suboptimization  is  at  the 
expense  of  the  overall  objective.  Also, 
incremental  improvements  may  not 
be  good  enough  for  a  company  or 
department  (or  system  program  of¬ 
fice)  in  real  trouble.  Reengineering 
compels  a  manager  to;  consider  the 
complete  organization  as  one  pro¬ 
cess,  revisit  the  operational  objec¬ 
tives.  and  change  the  work  approach 
to  better  meet  the  clarified  objectives. 
Their  bottom  line  is:  radical  changes 
to  the  way  you  work  can  radically 
improve  your  performance. 

This  excellent  book  starts  with  a 
comparison  of  the  author’s  theory  of 
business  management  to  that  of  Adam 
Smith.  In  his  The  Wealth  of  Nations, 
Smith  explained  the  principle  of  the 
division  of  labor.  The  division  of  labor 
required  workers  to  specialize.  Com¬ 
panies  were  organized  around  tasks 
and  typified  by  elaborate  control  sys¬ 
tems  and  hierarchical  management 
structures.  Both  the  assembly  line  and 


the  functional  organization  are  re¬ 
sults  of  Adam  Smith’s  1776  work. 
These  principles  were  at  their  nadir 
during  the  tenures  of  Henry  Ford  and 
Alfred  Sloan  (at  General  Motors). 

Reengineering  requires  companies 
to  organize  around  processes.  It  is  not 
for  the  fainthearted.  The  authors  be¬ 
lieve  companies  who  want  to 
reengineer  must,  “starting  from 
scratch,”  be  willing  to  accept  risk,  and 
have  (or  institute)  a  spirit  of  individu¬ 
alism,  self-reliance  and  a  propensity 
for  change.  Most  importantly,  they 
must  challenge  the  fundamental  as¬ 
sumptions  upon  which  the  organiza¬ 
tion  operates. 

Ford  Motor  Company,  for  example, 
wanted  to  reduce  their  accounts  pay¬ 
able  department  from  more  than  500 
to  400  people.  When  Ford  acquired  a 
25-percent  interest  in  Mazda,  they 
noticed  that  the  Mazda  accounts  pay¬ 
able  department  consisted  of  only  five 
people.  This  forced  Ford  to  rethink 
their  entire  parts  procurement  pro¬ 
cess.  Previously,  accounts  payable 
oversaw  completion  of  three  docu¬ 
ments  for  each  transaction  —  a  pur¬ 
chase  order  to  request  the  part  from  a 
vendor,  another  form  to  document 
receipt  of  the  part,  and  the  invoice  or 
bill  from  the  vendor  to  request  pay¬ 
ment.  The  accounting  clerks  spent 
much  of  their  time  resolving  discrep¬ 
ancies  among  these  three  documents. 
Under  the  new  process,  a  buyer  en¬ 
ters  the  order  into  an  on-line  data¬ 
base  when  the  part  is  requested.  When 
the  order  arrives,  the  database  is  con¬ 
sulted  to  match  the  order  to  the  pur¬ 
chase  request.  If  they  don’t  match, 
the  order  is  refused.  The  new  process 
employs  about  125  people. 


Reengineering  is  about  substantive 
change  and  radical,  not  incremental, 
improvv  nents. 

The  book  is  easy  to  read  and  well- 
indexed.  It  provides  four  case  studies 
to  illustrate  reengineering  theory  in 
action.  In  the  scenarios.  Hallmark, 
Taco  Bell,  Capital  Holding  and  Bell 
Atlantic  are  analyzed  as  they  use 
reengineering  to  make  their  opera¬ 
tions  quicker  and  more  flexible,  im¬ 
prove  customer  satisfaction,  and  cut 
costs.  One  chapter  helps  determine  if 
your  company  is  a  good  candidate  for 
reengineering.  Summary  information 
on  how  to  complete  the  reengineering 
process  is  given,  also.  Managers  with 
experience  in  developing  and  imple¬ 
menting  vision  statements  will  be  on 
familiar  ground  here. 

Hammer  and  Champy  aren’t  rest¬ 
ing  on  their  laurels.  According  to  the 
Wall  Street  Journal,  their  respective 
management  consultant  businesses 
are  flooded  with  speaking  and  train¬ 
ing  requests.  Each  is  working  on  a 
sequel  —  Champy,  on  Reengineering 
Management  and  Hammer  on  Beyond 
Reengineering.  If  these  books  are  half 
as  good  as  their  joint  effort,  they  will 
be  well  worth  reading. 

Major  Edward  L.  Bolton,  Jr.,  USAF, 

Chief,  Upper  Stages  Engineering 
Branch, Titan  Systems  Program  Of¬ 
fice,  Space  and  Missile  Systems  Cen¬ 
ter.  Los  Angeles  AFB.  Calif.  He  is  a 
PMC  94-1  graduate. 
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A  LEARNING  CURVE  BEGINS 


TRAVELING  CONTACT  TEAM 
ASSISTS  BULGARIA 

DSMC  Professors  I'^rcscni  Uvcr\'icw> 


Randy  C.  Zittel  •  Charles  B.  Cochrane  •  Gary  /.  Hagan  •  John  P.  McGovern 


re  U.S.  European  Command 
(USEUCOM)  Military-to-Mili- 
tary  Contact  Program  is  an  out¬ 
reach  to  the  newly  emerging 
countries  of  Central  and  Eastern  Eu¬ 
rope  and  assigned  republics  of  the 
former  Soviet  Union.  The  mission  is 
to  assist  designated  foreign  military 
forces  to  develop  into  positive,  con¬ 
structive  elements  of  society  during 
their  country’s  transition  to  democ¬ 
racy  and  a  free-market  economy. 

As  these  nations  disengage  from  a 
Soviet-style  military,  the  U.S.  military 
offers  an  effective  role  model  of  a 
military  under  civilian  control.  Estab¬ 
lished  by  both  a  Secretary  of  State 
policy  and  an  accompanying  Depart¬ 
ment  of  Defense  (DoD)  Joint  Chiefs  of 
Staff  memorandum  in  April  1992,  no 
formal  education,  training,  equip¬ 
ment,  or  hardware  will  be  offered 
through  the  program,  to  avoid  conflict 
with  existing  U.S.  foreign  military  sales 
programs.*  The  USEUCOM  program 
consists  of  the  following  four  elements: 

—  A  permanent  (U.S.  military) 
Contact  Team  Program  Office  at 
USEUCOM  headquarters  led  by  a 
flag  officer  and  staffed  with  desk  offic- 

•The  North  Atlantic  Treaty  Organization 
(NATO)  has  a  similar  assistance  pro¬ 
gram.  Since  “the  best  defense  is  to 
make  an  enemy  your  friend”  and  eco¬ 
nomic  stability  is  essential  for  these 
countries  to  seed  in  their  democratiza¬ 
tion,  both  U.S.  and  NATO  programs 
are  positive  efforts  to  assist  this  pro¬ 
cess  peacefully  within  the  sovereign 
integrity  of  these  nations. 


The  U.S. 
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ers  (one  per  country),  functional  area 
specialists,  and  an  administrative 
staff. 

—  Military  Liaison  Teams  estab¬ 
lished  in  a  country  by  USEUCOM 
under  the  jurisdiction  of  the  U.S. 
ambassador  to  that  country  to  coordi¬ 
nate  support  and  assistance. 

—  Traveling  Contact  Teams  (TCT) 
consisting  of  U.S.  military  and  civil¬ 
ian  professionals  providing  expertise 
to  the  host  nation  in  a  specific  func¬ 
tional  area,  and  tailored  to  the  host 
nation’s  specific  request. 

—  Familiarization  Tours  for  host 
nation  personnel  who  tour  U.S.  facili¬ 
ties  in  Europe  or  the  continental 
United  States  in  conjunction  with  an 
American  National  Guard  State  Part¬ 
nership.  Bulgaria  is  partnered  with 
the  state  of  Tennessee  and  its  Na¬ 
tional  Guard.  The  state  hosts  liaison 
visits  to  U.S.  cities  where  Bulgarians 
learn  firsthand  about  U.S.  industry 
practices  in  companies  located  in 
Tennessee.  The  Guard  provides  a 
military  forum  that  acts  as  a  positive 
model  for  the  civilian-controlled 
militia. 

Military  Liaison  Teams  are  located 
in  Albania,  Belarus,  Bulgaria,  Czech 
Republic,  Estonia,  Hungary,  Latvia, 
Lithuania,  Poland,  Romania  and 
Slovakia. 

As  part  of  a  TCT.  four  Defense 
Systems  Management  College 
(DSMC)  professors  participated 
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recently  in  the  USEUCOM  prognim 
in  Bulgaria.  The  TCT  was  hosted  by 
Colonel  Richard  T.  Lee,  USAF.  head 
of  the  in-countr/  Military  Liaison 
Team  (MLT)  to  Bulgaria,  and  led  by 
Colonel  David  S.  Kiefer,  International 
Cooperative  Programs,  Office  of  the 
Secretary  of  Defense.  (Another  DSMC 
team  subsequently  has  visited  Hun¬ 
gary  under  this  program.)  The  Bulgar¬ 
ian  MLT  had  been  in  existence  for 
only  nine  months  when  we  visited, 
but  we  were  the  62nd  team  to  visit. 

The  following  week,  the  MLT  was 
coordinating  an  aviation  team  from 
the  U.S.  Federal  Aviation  Administra¬ 
tion,  to  coordinate  air  traffic  control 
issues,  and  an  environmental  pollu¬ 
tion  team  to  help  Bulgaria  attack  the 
serious  multinational  pollution  issue 
in  the  Black  Sea. 

The  Bulgarians  were  friendly  and 
welcomed  us  with  open  arms.  They 
explained  to  us  during  the  course  of 
the  week  that  one  of  Bulgaria’s  prime 
contributions  to  the  former  Warsaw 
Pact  was  electronics  development  and 
production  capability.  It  was  this  com¬ 
munity  within  their  Ministry  of  De¬ 
fense  (MOD)  which  requested  assis¬ 
tance  through  the  U.S.  program.  Led 
by  Professor  (Doctor)  Boyal  Petkov, 
Director  of  the  entire  MOD  Research 
and  Development  Directorate,  and 
Brigadier  General  Dragomir  Ivanov, 
Director  of  the  Military  Industry  Di¬ 
rectorate,  they  are  focused  on  apply¬ 
ing  their  existing  electronic  industry 
to  U.S.  and  NATO  defense  and  com¬ 
mercial  markets. 

We  found  the  team’s  Bulgarian 
counterparts  to  be  sharp,  friendly, 
and  well-educated.  Their  capital  city, 
Sofia,  where  we  stayed,  is  active,  busy 
and  proud  of  its  long  regional  history. 
The  professionals  with  whom  we  met 
were  open-minded  and  eager  to  tackle 
this  new  freedom  to  compete  in  new 
markets  throughout  the  world. 

The  agenda  consisted  of  plenary 
sessions,  a  tour  and  visit  to  the  Elec¬ 
tron  Progress  Company,  and  separate 


working  sessions  with  Bulgarian  spe¬ 
cialists  on  research  and  development, 
engineering,  manufacturing,  specifi¬ 
cations,  standards  and  patents. 

The  TCT  also  hosted  an  "icebreaker 
social  "  for  the  Bulgarian  team,  to 
which  the  Bulgarians  reciprocated  by 
hosting  an  end-of-visit,  three-hour 
luncheon.  Anyone  who  has  ever 
worked  with  Europeans  knows  how 
much  fun  their  farewell  activities  be¬ 
come. 

Twenty-one  officials  of  the  Bulgar¬ 
ian  Ministry  of  Defense  attended  the 
plenary  sessions  and  working  groups 
related  to  their  area  of  expertise.  It 
took  time  to  establish  a  common 
ground  and  develop  the  specific  areas 
of  Bulgarian  interest,  which  is  normal 
in  international  technical  exchanges. 
The  discussions  were  open  and  ex¬ 
tensive,  although  limited  by  the  re¬ 
quired  back-and-forth  language-trans¬ 
lation.  Shown  below  is  a  summary  of 
the  presentations  and  working  group 
sessions: 

Plenary  Sessions 

Charles  B.  Cochrane,  Acquisition 
Policy  Department,  DSMC,  gave  an 
overview  of  defense  acquisition  policy 
and  procedures  and  the  Planning, 
Programming  and  Budgeting  System; 
Gary  ).  Hagan,  Acquisition  Policy 
Department,  DSMC,  the  military  re¬ 
quirements  generation  system  and 
system  life-cycle  management;  Randy 
C.  Zittel,  Systems  Engineering  Man¬ 
agement  Department,  DSMC,  the  sys¬ 
tems  engineering  management  and 
military  specifications  and  standards; 
and  John  P.  McGovern,  Manufactur¬ 
ing  Management  Department,  DSMC, 
an  overview  of  manufacturing  man¬ 
agement  and  quality  assurance. 

Policy  and  Program  Management 
Working  Group 

The  sessions  were  hosted  by  LTC 
(Engineering)  Vladimir  Takov  and 
attended  by  Bulgarian  defense  pro¬ 
gram  managers  (PMs)  at  the  Senior 
Assistant  (Major)  and  Branch  Chief 
(LTC)  levels. 


An  ad  hoc  and  wide-ranging  dis¬ 
cussion  touched  on  the  relative  pow¬ 
ers  and  responsibilities  of  the  PM  and 
milestone  decision  authority,  the 
qualifications  and  selection  of  PMs. 
the  contracting  process,  international 
cooperative  development,  testing  and 
test  types,  the  appropriations  process, 
contract  management,  cost  issues 
associated  with  small-scale  produc¬ 
tion  of  defense  systems,  the  U.S.  For¬ 
eign  Comparative  Testing  Program, 
and  export  controls  on  U.S.  defense 
articles  and  technologies. 

Responding  to  perceived  interest 
in  how  the  United  States  contracted 
for  defense  materiel.  Professor 
Cochrane  delivered  a  45-minute  pre¬ 
sentation  on  contracting  procedures 
as  part  of  the  working  group’s  agenda. 

Specifications  and  Standards 
Working  Group 

Bulgarian  members  of  the  working 
group  were  engineers  and  specifica¬ 
tion  document  specialists  whose  ar¬ 
eas  of  interest  were  U.S.  military  speci¬ 
fications  and  standards,  quality 
assurance,  and  the  implementation 
of  the  ISO  9000  quality  standards  and 
patents. 

The  discussion  was  open  and  ex¬ 
tensive.  It  centered  on  the  legal  basis 
for  U.S.  military  specifications  and 
standards,  the  administrative  process 
for  developing  U.S.  specifications  and 
standards,  the  applicability  of  mili¬ 
tary  standards  and  specifications  to 
commercial  work,  patent  rights  of  tech¬ 
nical  information  developed  under 
U.S.  government  contracts,  differ¬ 
ences  between  U.S.  military  standards 
and  NATO  standards,  the  manner  in 
which  the  U.S.  government  exercises 
control  over  the  production  of  mili¬ 
tary  articles,  and  the  NATO  codifica¬ 
tion  system  for  defense  items. 

The  Bulgarian  team  specifically 
requested  13  U.S.  military  standards 
and  specifications  which  dealt  with 
telecommunications  and  associated 
electronics.  This  is  indicative  of  their 
interest  in  applying  their  electronic 
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production  capabilities  in  order  to 
qualify  as  a  U.S.  source.  These  docu¬ 
ments,  along  with  patent-related  por¬ 
tions  of  the  Federal  Acquisition  Regu¬ 
lations  and  the  DoD  Index  of 
Specifications  and  Standards,  have 
been  forwarded  by  DSMC  through 
the  U.S.  Military  Liaison  Team  to  the 
Bulgarian  MOD. 


here  to  watch  bright  and  talented 
people  try  to  understand  the  concepts 
of  freedom  and  free  enterprise  in  one 
fell  swoop.  As  is  so  often  the  case 
across  cultural  borders,  the  Bulgar¬ 
ians  were  concerned  about  worst  case 
issues  in  the  free  enterprise  system. 
This  concern  was  focused  on  their 
potential  loss  of  their  technical  rights. 


particular  market  is  based  mainly  on 
their  dynamic  ability  to  meet  change 
and  their  internal  technological  lead. 

Visit  to  the 

Electron  Progress  Company 

The  DSMC  contingent  of  the  TCT 
visited  the  Electron  Progress  Com¬ 
pany  and  was  hosted  by  the  company 
director,  Mr.  Ivan  Nicolov  and  his 
staff.  Although  Electron  Progress  is 
entitled  a  company,  it  is  really  a  cap¬ 
tive  MOD  radio  design  laboratory'. 
The  "contracts”  the  company  receives 
from  MOD  are  really  production  or¬ 
ders  for  military  radios.  Any  sub¬ 
systems,  such  as  microelectronics,  are 
“subcontracted”  to  another  MOD  fa¬ 
cility,  which  exclusively  fabricates  the 
required  microchips. 

Based  on  the  discussions  at  the 
facility,  their  apparent  capability  in 
the  microchip  area  is  only  at  the  me¬ 
dium  scale  of  integration.  Their  radio 
technology  is  digital  and  their  scien¬ 
tific  research  is  current.  They  also 
review  U.S.  and  Western  technical 
publications  closely.  According  to  the 
Bulgarians,  visits  have  been  made  by 
U.S.  Department  of  Commerce  teams 
with  American  industrial  representa¬ 
tives,  but  no  U.S.-Bulgarian  teaming 
arrangements  have  resulted,  as  yet. 

Observations  and 
Conclusions 

The  Bulgarians  seem  familiar  with 
issues  related  to  modern  program 
management  of  weapons  systems  and 
the  accompanying  policy  questions. 


An  interesting  discovery  in  this 
working  group  was  when  the  Bulgar¬ 
ians  explained  that  their  country  had 
no  patent,  trademark  or  copyright 
laws.  Although  their  legislature  has 
just  passed  a  patent  law,  the  whole 
concept  of  patent  rights  was  foreign  to 
them,  and  essentially  comes  on  the 
immediate  heels  of  the  dissolution  of 
the  Warsaw  Pact  where  state  owner¬ 
ship  of  everything  was  so  complete. 


Western  industry  has  created  an 
interlocking  and  complex  web  of  tech¬ 
nical  rights  ownership  through  de¬ 
cades  of  evolving  national  and  inter¬ 
national  patent,  trademark  and 
copyright  law.  Bulgaria  has  no  patent 
attorneys,  so  the  MOD  engineers  ad¬ 
dress  the  issues  in  parallel  with  their 
other  branches  of  government  which 
are  trying  to  develop  capability  in 
these  important  new  areas. 


The  ensuing  conversation  demon¬ 
strated  the  fascinating  opportunity 


As  every  Western  company  knows, 
their  lead  (or  lack  thereoO  in  their 


They  have  an  intense  interest  in 
upgrading  their  manufacturing  and 
technology  base:  therefore,  the 
majority  of  their  interest  centered  on 
subject  areas  relating  to  engineering 
and  manufacturing  areas  (i.e.,  speci¬ 
fications,  standards,  commercial/in¬ 
dustrial  practices,  patents,  the 
contracting  process,  and  contract 
management). 

Since  the  Bulgarian  defense  indus¬ 
try  remains  fully  government  owned, 
their  understanding  of  the  competi- 
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tive  contracting  process  is  especially 
weak.  As  noted  earlier.  DSMC  has 
forwarded  additional  information  re¬ 
lated  to  specifications  and  standards 
to  the  Bulgarian  MOD  through  the  in¬ 
country  MLT  in  the  near  future. 

The  Bulgarian  delegation  clearly 
demonstrated  a  totally  different  con¬ 
cept  of  the  contract.  To  them  it  repre¬ 
sents  a  service  order  from  one  govern¬ 
mental  echelon  to  another  which 
cannot  be  refused.  The  competitive, 
open  nature  of  obtaining  the  contract, 
along  with  the  American  system  of 
c<  t  performance  was  a  foreign 
't,  and  much  discussion  was 

V  in  trying  to  explain  this. 

Their  questions  were  directed  at 
the  end  of  the  process  to  the  applica¬ 
tion  of  contractually-required  military 
specifications,  and  how  such  stan¬ 
dards  evolve  into  military  programs 
through  the  contracted  acquisition 
process.  As  previously  mentioned,  the 


Bulgarian  government  has  just  en¬ 
acted  a  patent  law,  which  increased 
their  interest  in  applying  this  to  their 
infrastructure. 

As  we  went  deeper  into  our  system 
of  "open  markets"  and  “free  enter¬ 
prise”  during  the  working  group  ses¬ 
sions,  we  were  proud  of  how  well 
American  industry  works.  As  we  dis¬ 
cussed  issues  of  quality  assurance. 
Defense  Contract  Management  Com¬ 
mand  (DCMC),  etc.,  we  were  taken 
back  when  the  Bulgarians  drew  a  par¬ 
allel  between  their  government-owned 
captive  industry  and  American  indus¬ 
try  with  extensive  program  office  and 
DCMC  in-plant  representatives  moni¬ 
toring  every  step  of  the  development 
and  production  process. 

In  the  plenary  and  group  sessions 
it  was  mentioned,  also,  how  our  ma¬ 
jor  system  acquisition  programs  have 
strong  DoD  and  congressional  over¬ 
sight.  The  TCT  free-market  nonexp>erts 
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3.  DoD  Instruction  2015.4,  “Mutual 
Weapons  Development  Data 
Exchange  Program  and  Defense 
Development  Exchange  Program,” 
November  5,  1963. 

4.  Under  Secretary  of  Defense 
(Policy)  Memorandum  1-93/16347, 
Subject:  Security  Arrangements  for 
Multinational  Armament  Cooperative 
Programs,  September  21,  1993.  Docu¬ 
ment  Number  4.,  “Security  Clauses,” 
paragraph  2  -  “Clauses  Governing 
Visits”;  and  Document  Number  7, 
“International  Visit  Procedures.” 

5.  DoD  Instruction  2015.4,  “Mutual 
Weapons  Development  Data  Ex¬ 
change  Program  and  Defense  Devel¬ 
opment  Exchange  Program,”  Novem¬ 
ber  5,  1963. 

6.  DoD  Directive  2000.9,  “DoD  Par¬ 
ticipation  in  International  Technical 
Exchange,  Cooperative  and  Copro¬ 
duction  Programs.”  Draft. 

7.  DoD  Directive  5230.11,  “Disclo¬ 


sure  of  Classified  Military  Informa¬ 
tion  to  Foreign  Governments  and  In¬ 
ternational  Organizations,”  Decem¬ 
ber  31,  1994. 

8.  DoD  Directive  5530.3,  “Interna¬ 
tional  Agreements,”  June  II,  1987. 

9.  Title  10  U.S.  Code. 

10.  Section  27  of  the  Arms  Export 
Control  Act  (22  U.S.  Code  2767,  “Au¬ 
thority  of  the  President  to  Enter  into 
Cooperative  Projects  with  Friendly 
Foreign  Countries.” 

11.  Section  2350a  of  Title  10,  U.S. 
Code,  “Cooperative  Research  and 
Development  Projects:  Allied  Coun¬ 
tries.” 

12.  “Is  U.S.  Business  Obsessed  with 
Ethics?”  Daniel  Vogel,  Across  the 
Board:  The  Conference  Board  Maga¬ 
zine,  November/December  1993. 

13.  DoD  Directive  1005.13,  “Gifts 
from  Foreign  Governments,”  October 
13,  1988;  Change  1  dated  February 
21,  1990.  This  directive  allows  for 


explained  that  the  key  difference  is 
that  private  industry  has  ownership 
of  their  technology  and  the  ability  to 
compete  or  not  compete  for  new  work. 
Also,  the  continuous  DoD  Acquisi¬ 
tion  Reform  effort  is  to  empower  the 
engineering  strength  of  our  private 
sector,  but  it  must  live  in  the  real 
world  of  tax  dollars  at  work. 

No  further  DSMC  assistance  is 
scheduled.  The  focus  of  the  USEUCOM 
program  is  to  assist  each  nation  with 
what  they  want  as  they  want  it.  Once 
they’ve  had  a  chance  to  study  the  for¬ 
warded  U.S.  specifications  and  regula¬ 
tions,  they  may  call  upon  another  team 
to  extend  the  learning  curve.  Free-mar¬ 
ket  forces  are  strongly  at  work  on  the 
Bulgarian  people  from  outside,  causing 
them  to  spread  their  valuable  resources 
thin  as  they  embrace  so  much  opportu¬ 
nity  so  fast. 


periodic  increases  in  the  value  of  gifts 
of  minimal  value. 

14.  Public  Law  95-105,  “Receipt  and 
Disposition  of  Foreign  Gifts  and  Deco¬ 
rations.”  August  17,  1977. 

15.  Section  2350b  of  Title  10,  U.S. 
Code,  “Acquisition  of  Defense  Equip¬ 
ment  Under  Cooperative  Projects.” 
Original  Quayle  Amendment,  further 
amended. 

16.  Section  65  of  the  Arms  Export 
Control  Act  (22  U.S.C.  2796),  “Leases 
of  Defense  Articles  and  Loan  Author¬ 
ity  for  Cooperative  Research  and  De¬ 
velopment  Purposes.” 

17.  The  Cultural  and  Political  Envi¬ 
ronment  of  International  Business:  A 
Guide  for  Business  Professionals,  Don 
Alan  Evans,  McFarland  &  Compai 
Inc.,  1991.  This  reference  contains 
especially  good  write-up  on  gendc, 
as  well  as  other  related  considerations, 
such  religion  and  culture. 
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SOFTWARE  ACQUISITION 
MANAGEMENT  MATURITY 
MODEL  (SAM^) 

A  CoiKcpt 

Emanuel  R.  Baker  •  Lee  Cooper  •  Barry  A.  Corson  •  Arthur  E.  Stevens 


ftware  has  become  a  major  tech¬ 
nical  and  cost  concern  in  all  cor¬ 
ners  of  the  federal  government. 
The  amount  of  money  spent  an¬ 
nually  on  software  acquisition  and 
development  grows  at  approximately 
12  percent.  The  added  functionality 
demanded  from  software  grows  at  an 
even  faster  rate.  In  fact,  today’s  mod¬ 
em  systems  have  become  so  complex 
and  software  intensive  they  are  un¬ 
able  to  perform  any  portion  of  their 
mission  without  software. 

In  the  Department  of  Defense 
(DoD),  an  increasingly  greater  pro¬ 
portion  of  the  money  is  spent  on  soft¬ 
ware  in  weapon  system  acquisition 
and  modernization.  At  the  same  time, 
software  has  become  one  of  the  most 
mission  critical,  and  yet  difficult-to- 
manage  components  in  the  DoD 
weapon  systems.  Historically,  soft¬ 
ware  development  has  not  been  man- 
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aged  and  controlled  well.  This  has 
resulted  in  software  deliveries  that 
are  behind  schedule,  over  budget,  and 
contain  significant  errors.  This  in¬ 
creased  reliance  on  software  and  the 
inability  of  our  software  development 
contractors  to  deliver  quality  software 
on  time  and  within  budget  has  cre¬ 
ated  a  “crisis”  in  the  software  indus¬ 
try.  This  crisis  demands  close  atten¬ 
tion  by  highly  experienced  and 
software-knowledgeable  program 
managers  (PMs). 

The  Office  of  the  Secretary  of  De¬ 
fense  (OSD)  and  the  Services  have 
been  addressing  the  software  devel¬ 
opment  problem  for  some  time.  A 
number  of  initiatives,  including  the 
development  of  standards,  introduc¬ 
tion  of  Ada,  research  into  new  tech¬ 
nologies  and  methodologies,  and  de¬ 
velopment  of  process  assessment 
techniques,  have  been  undertaken  to 
improve  the  contractor’s  software  de¬ 
velopment  activities.  On  the  other 
hand,  very  few,  if  any,  significant  ini¬ 
tiatives  have  addressed  the  processes, 
methods  and  tools  used  by  DoD  PMs 
in  software  acquisition  management. 
Nothing  in  use  today  characterizes 
and  measures  the  capability  of  pro¬ 
gram  management  offices  to  manage 
and  control  software  acquisitions  ef¬ 
fectively. 

To  meet  that  need,  we  have  under¬ 
taken  a  study  to  characterize  and 


measure  the  capability  of  program 
management  offices  to  manage  and 
control  mission  critical  computer  soft¬ 
ware  (MCCS)  acquisition.  The  pur¬ 
pose  of  this  study  is  to  develop  a 
Software  Acquisition  Management 
Maturity  Model  (SAM’). 

The  SAM’,  a  hierarchical  structure 
of  Key  Process  Areas,  Key  Practices 
and  Key  Indicators  (see  Figure  1)  has 
each  Key  Process  Area  (KPA)  orga¬ 
nized  into  five  levels  of  maturity,  simi¬ 
lar  to  that  of  the  Software  Engineering 
Institute  (SEI)  Capability  Maturity 
Model  (CMM).  The  acquisition  man¬ 
agement  maturity  model  would  then 
become  the  basis  for  assessments  of 
the  acquisition  management  capabil¬ 
ity  of  the  organization.  As  with  soft¬ 
ware  process  assessments  (the  per¬ 
formance  of  which  are  based  on  the 
CMM),  the  assessment  would  result 
in  a  set  of  findings,  corresponding 
recommendations,  and  an  action  plan 
to  facilitate  the  implementation  of  the 
recommendations,  based  on  the  struc¬ 
ture  of  the  SAM’  model. 

While  the  impetus  for  this  study 
originated  within  the  DoD,  the  prob¬ 
lem  is  common  to  many  organiza¬ 
tions  that  acquire  software  in  both  the 
defense  and  private  sectors  of  the 
economy.  Whether  we  are  talking 
about  acquiring  an  off-the-shelf  man¬ 
agement  information  system  applica¬ 
tion,  acquiring  utility  software  pack- 
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ages,  or  libraries  of  functions  to  incor¬ 
porate  into  production  scientific  or 
engineering  applications,  organiza¬ 
tions  that  acquire  software  often  have 
been  prone  to  misadventures  in  such 
software  acquisition. 

Although  developec  to  character¬ 
ize  the  acquisition  of  MCCS  for  mili¬ 
tary  systems,  the  model  described  in 
this  article  contains  many  principles 
that  can  be  applied  to  the  acquisition 
of  MCCS  for  any  organization  —  com¬ 
mercial,  information  systems,  mili¬ 
tary,  government,  defense  contractor, 
etc.  —  that  acquires,  from  outside 
sources,  software  that  is  critical  to  the 
mission  of  the  organization  or  the 
quality  of  its  deliverable  products.  It 
can  be  tailored  to  fit  the  needs  of  any 
such  organization  —  in  many  cases, 
by  merely  substituting  the  appropri¬ 
ate  acronyms. 

This  article  describes  the  model 
and  its  underlying  concepts. 

Underlying  Concepts 

Efforts  have  been  made  to  charac¬ 
terize  the  maturity  of  various  kinds  of 
endeavors.  Examples  are  models  to 
characterize  the  capability  of  organi¬ 


zations  to  develop  software,  and  those 
to  characterize  the  measurement  tech¬ 
nology  maturity  of  organizations.  One 
of  the  better-known  models  to  char¬ 
acterize  the  capability  of  software  de¬ 
velopment  organizations'  ’  is  the 
Capability  Maturity  Model  (CMM). 

Developed  at  the  Software  Engi¬ 
neering  Institute  (SEI)  of  Carnegie 
Mellon  University,  Pittsburgh,  Pa., 
under  the  guiding  hand  of  Watts 
Humphrey,  this  model  identifies  five 
levels  of  maturity:  Initial,  Repeatable, 
Defined,  Managed  and  Optimizing. 
Each  level  has  key  processes  associ¬ 
ated  with  it,  excepting  Level  1  (Initial 
Level),  in  which  no  formalized  key 
processes  exist.  In  other  words,  soft¬ 
ware  development  is  performed  by 
applying  ad  hoc  management  and 
development  practices. 

On  the  other  hand,  a  Level  2  orga¬ 
nization  is  characterized  as  one  that 
has  the  project  planning  and  manage¬ 
ment,  configuration  management, 
quality  assurance,  requirements  man¬ 
agement,  and  subcontractor  manage¬ 
ment  key  processes  in  place,  and  is 
operating  in  accordance  with  these 
prescribed  practices.  The  Level  2  fo¬ 


cus  is  the  project  management  prac¬ 
tices  of  the  organization. 

At  Level  3,  the  organization  has 
defined  and  codified  the  software  de¬ 
velopment  practices,  and  has  insti¬ 
tuted  training  in  them.  The  primary 
concern  in  Levels  1-3  is  for  establish¬ 
ing  a  defined  and  repeatable  process 
to  achieve  uniformity  in  the  quality  of 
the  software  products. 

Beginning  with  Level  4,  the  focus 
of  the  organization  shifts  to  process 
improvement  in  order  to  achieve  bet¬ 
ter  levels  of  quality  in  the  software 
product.  At  Level  4,  process  measures 
have  been  established,  and  a  data¬ 
base  of  process  measures  is  being 
collected.  Corrective  action  is  insti¬ 
tuted,  as  necessary,  to  maintain  the 
performance  of  existing  processes 
within  acceptable  bounds.  At  Level  5, 
the  process  measures  are  being  used 
to  provide  feedback  for  process  im¬ 
provement,  and  continuous  optimi¬ 
zation  of  the  processes  is  being  per¬ 
formed. 

The  key  processes  cluster  into  key 
process  areas  (KPAs),  considered  to 
be  essential  building  blocks  for  the 
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TABLE  I.  SifftiViirc  Aci/iiisitio/:  Mitiur  t\'  ’  / 

Associated  KPA  Charucteristii  s 


Level  Deecription 

1  Initial 

2  Repeatable 

3  Defined 

I 

I  4  Managed 

i 

j  5  Optimizing 


Characteristics 

The  processes  associated  with  this  KPA  are  performed  in  an  ad  hoc  manner.  No  key  practices  are  in 
place  (formalized)  to  implement  the  KPA.  The  organization  is  completely  event-  and  interrupt-driven 
with  regard  to  this  KPA,  and  tends  to  operate  in  a  fire-fighting  mode. 

Some  rudimentary,  bare-bones  key  practices  are  in  place  for  this  KPA,  but  not  all  that  should  be  per¬ 
formed.  Those  that  are  in  place  are  performed  per  management  direction,  but  they  may  or  may  not  be 
codified.  Variability  may  exist  in  the  performance  of  the  key  practices  from  individual  to  individual. 

All  the  key  practices  that  should  be  performed  for  this  KPA  are  codified  and  are  performed  per  man¬ 
agement  direction. 

Measures  of  the  effectiveness  of  the  processes  within  this  KPA  have  been  defined  and  verified  as  ap¬ 
propriate  for  the  KPA.  A  project  database  of  these  measures  is  being  collected.  The  measures  are 
being  fed  into  a  database  for  the  acquisition  organization  so  that  improvement  of  the  acquisition  pro¬ 
cess  within  the  entire  organization  can  be  effected. 

The  defined  measures  are  being  analyzed  and  used  to  optimize  the  acquisition  process. 


maturation  of  the  organization  from 
the  initial  level  to  the  optimizing  level 
—  in  other  words,  process  improve¬ 
ment.  In  constructing  buildings,  each 
new  row  of  bricks  must  build  on  the 
previous  row.  In  the  same  manner, 
the  building  blocks  at  one  level  of  the 
CMM  must  all  be  in  place  before 
going  on  to  the  next.  At  each  level  of 
the  CMM,  the  key  processes  essen¬ 
tially  must  be  fully  operative  for  the 
organization  to  be  considered  as  func¬ 
tioning  at  that  specific  level  of  the 
CMM. 

On  the  surface,  it  would  appear  the 
CMM  has  KPAs  that  are  unique  to  a 
specific  level  of  the  model;  i.e.,  all 
aspects  of  that  KPA  must  be  in  place 
at  the  level  with  which  it  is  related. 

ElGllRi:  2.  Sofirrurv  .U'riir 
Maturity  .  *  I  o  d  i:  I 


For  instance,  training  is  a  KPA  associ¬ 
ated  with  Level  3.  The  inference  could 
be  drawn  that  training  is  instituted 
only  in  improving  from  Level  2  to 
Level  3  This  is  not  a  correct  interpre¬ 
tation.  Elements  of  training  neces¬ 
sary'  for  the  organization  to  achieve 
Level  2  on  the  CMM  will  evolve  when 
going  from  Level  1  to  Level  2.  Careful 
scrutiny  of  the  recently  revised  CMM 
reveals  the  threading  of  the  key  prac¬ 
tices  associated  with  any  key  process 
through  the  KPAs  at  increasingly 
higher  levels  of  maturity.' 

Looking  at  other  arenas  where 
maturity  models  have  been  developed, 
Daskalantonakis,  Yacobellis  and 
Basili,^  have  characterized  the  soft¬ 
ware  measurement  technology  matu¬ 


rity  of  organizations  in  a  manner  simi¬ 
lar  to  that  of  the  SEl’s  CMM.  Their 
model  consists  of  five  levels,  and  the 
definitions  of  the  five  levels  are  iden¬ 
tical  to  that  of  the  CMM.  One  major 
difference  between  the  CMM  and  the 
maturity  model  proposed  by 
Daskalantonakis  et  al  is  that  the  mea¬ 
surement  technology  maturity  model 
is  comprised  of  10  themes,  each  of 
which  has  definable  characteristics 
existing  at  each  level  of  maturity.  For 
instance.  Formalization  of  the  Mea¬ 
surement  Process  is  one  of  the  themes. 
The  characteristic  of  this  theme  at 
Level  1  is  that  there  is  no  formaliza¬ 
tion.  At  Level  2,  formal  procedures 
are  established.  At  Level  3.  the  stan¬ 
dards  are  documented  and  applied. 
Improvement  mechanisms  are  in 
place  at  Level  4,  and  the  organization 
has  learned  and  improved  at  Level  5. 

The  themes  proposed  by 
Daskalantonakis  et  al  are  analogous 
to  KPAs  in  the  CMM.  The  way  these 
themes  are  structured  has  a  great 
deal  of  appeal.  This  structure  shows  a 
more  explicit  maturation  in  an 
organization's  implementation  of  the 
various  development  processes.  A 
more  direct  way  of  characterizing  the 
maturation  of  the  organization  is  de¬ 
sirable,  whether  we  are  talking  of 
software  development  capability,  or 
acquisition  management  capability. 
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r  uiit 

KEY  PROCESS 
AREA 

REQUmEIMEMTS 

MANAGEMENT 


MCCS 

ACQUISITION 

MANAGEMENT 


SOFTWARE 

PROJECT 

MANAGEMENT 


SOFTWARE 

TECHNICAL 

MANAGEMENT 


TRAINING 


QUALITY 

ASSURANCE 


CONFIGURATION 

MANAGEMENT/ 

DATA 

MANAGEMENT 


SUPPORTABILJTY 


TESTAI«) 

EVALUATION 

(TEE) 


RISK 

MANAGEMENT 


Ki*\  /V4HtNs  Xn'ii  l^isi  npthijjs  i/s  t/  t>/  Muim 


LEVEL  1 
INITIAL 


LEVEL  2 
REPEATABLE 


LEVELS 

DEFINED 


LEVEL  4 
MANAGED 


No  procdss  exists.  Inputs  re- 
ceived  from  users  and  others 
accepted  on  faith. 


No  process  exists  to  provide 
MCCS  inputs  to  support  man' 
dated  DoD  or  Service  require¬ 
ments  for  the  acquisition  of  sys¬ 
tems. 

No  structure  exists  for  man¬ 
aging  program  office  activities 
and  those  of  st^iporting  gov¬ 
ernment  organizations.  No 
training  provided  in  skills 
needed  for  managing  MCCS 
acquisition. 


Contractor  managed  by  ad  hoc 
reviews  and  decisions. 


No  training  provided  in  skills 
needed  for  MCCS  acquisition. 


No  software  quality  assurance 
(SQA)  function  exists. 


Program  office  does  not  exer¬ 
cise  configuration  management 
(CM)  or  data  management  (DM) 
over  contractor-delivered 
documentation,  products. 

No  structure  exists  for  co¬ 
ordination  with  organizations 
outside  of  the  program  office  to 
adequately  define  supportability 
requirements.  Supportability 
requirements  are  not  ad¬ 
equately  addressed  in  solicita¬ 
tions. 

The  definition  of  the  T&E 
requirements  are  left  completefy 
up  to  the  contractor  and  DoD 
organic  elements  responsible 
for  T&E. 

No  risk  management  is  per¬ 
formed. 


Program  office  takes  charge  of 
requirements  definition  ac^; 
however,  no  codified  procedure 
exists.  Process  highly  depen¬ 
dent  on  key  individuais  taking 
charge. 

Requirement  tor  generating  in¬ 
puts  and  supporting  documen¬ 
tation  for  Service  or  DoD  sys¬ 
tem  acquisition  process  require¬ 
ments  IS  established. 

Program  office  tracks  internal 
costs,  schedules,  problem  res¬ 
olution.  Structure  established 
for  coordination  with  outside 
organizations,  but  is  not  codr- 
fied.  Training  is  provided,  but 
in  an  unorganized  fashion. 


Program  office  specifies  to  the 
contractor  some  subset  of  soft¬ 
ware  engineering  requirements, 
and  tracks  contractor  costs, 
schedules,  problem  identifi¬ 
cation  and  resolution. 

Training  is  implemented,  but  no 
formalized  training  plan  exists 
to  ensure  that  organizational, 
individual  needs  are  met. 

SQA  established,  but  no  formal 
prxedures  exist. 


Baselines  established  for  soft¬ 
ware  requirements,  other  ma¬ 
jor  deliverables.  A  repository  of 
such  materials  is  established. 

Supportability  is  addressed  in 
an  organized  fashion  in  the  pro¬ 
cess  of  preparing  solicitations, 
but  is  not  properly  addressed 
during  the  full-scale  develop¬ 
ment  and  post-deployment  soft¬ 
ware  support  activities. 

Responsibility  for  the  genera¬ 
tion  of  the  Test  &  Evaluation 
Master  Plan  is  assigned  to  a 
lead  person  for  T&E.  Test  and 
evaluation  is  addressed  in 
piecewise  fashion. 

Risk  management  is  imple¬ 
mented,  but  the  program  office 
is  dependent  primarily  on  the 
development  organization  for 
performing  it. 


Process  for  defining  software 
requirements  is  established, 
formalized  and  followed. 
Responsibilities  ot  ati  interfac¬ 
ing  organizations  are  identified. 

Process  for  managing  MCCS 
acquisition  and  generating  re 
quired  supporting  inputs  is  es¬ 
tablished  and  codified 

Instructions,  procedures  exist 
and  are  followed  for  tracking 
program  office  project  man¬ 
agement  performance.  Formal 
agreements  are  established 
and  followed  for  interfacing  with 
organizations  external  to  the 
program  office.  A  formalized 
training  plan  exists. 

Instructions,  procedures  speci¬ 
fying  appropriate  software  en¬ 
gineering  and  contractor  moni¬ 
toring  requirements  exist  and 
are  followed  for  comprehensive 
tracking  ot  contractor  perfor¬ 
mance. 

A  formalized  training  plan  ex¬ 
ists  to  ensure  that  organiza¬ 
tional,  growth  needs  are  met. 

Formalized  SQA  implemented 
for  monitoring  contractor,  pro¬ 
gram  office  performance. 


Formalized  CM  and  DM  im¬ 
plemented  for  all  project  deliv- 
arables  and  coordinated  with 
affected  software  support 
organjzatjon(s). 

Supportability  is  properly  ad¬ 
dressed  throughout  the  entire 
life  cycle  in  accordance  with 
documented  procedures  and 
agreements  with  the  software 
support  activities,  users  and 
other  field  activities. 

An  integrated  T&E  approach  is 
defined,  based  on  life-cycle 
considerations.  Planning  for, 
and  monitoring  of,  the  T&E  ef¬ 
fort  is  performed  in  accordance 
with  documented  procedures. 

A  formalized  risk  management 
process  is  in  place,  and  the 
primary  responsibility  for  its 
managment  is  placed  in  the  pro¬ 
gram  office. 


Measures  for  determining  the 
adequacy  of  the  requirements 
definition  process  are  estab¬ 
lished.  Corrective  measures 
are  implemented. 

Measures  for  determining  the 
adenuacy  of  the  MCCS  acqui¬ 
sition  management  process  are 
established.  Corrective  me: 
sures  are  implemented 

Measures  for  determining  the 
adequacy  of  the  project  over¬ 
sight  process,  interfaces  with 
organizations  external  to  the 
program  office,  and  staff  train¬ 
ing  are  established.  Corrective 
measures  are  implemented. 


Measures  for  determining  the 
adequacy  of  the  contractor 
management  process  are 
established.  Corrective  mea¬ 
sures  are  implemented. 


Measures  for  determining  the 
adequacy  of  the  training  pro¬ 
gram  are  established.  Correc¬ 
tive  measures  are  implemented. 


Measures  for  determining  the 
adequacy  of  the  CM  and  DM 
processes  are  established. 
Corrective  measures  are  imple¬ 
mented  where  necessary. 


Measures  for  determining  the 
adequacy  of  the  planning  and 
conduct  ot  the  T&E  effort  are 
established.  Corrective  mea¬ 
sures  are  implemented  where 
necessary. 

Measures  for  determining  the 
adequacy  of  the  risk  manage¬ 
ment  process  are  established. 
Corrective  measures  are  imple¬ 
mented.  where  necessary. 


LEVEL  5 
OPTIMIZING 

Measures  for  determining  the 
adequacy  ot  the  requirements 
definition  process  are  being 
used  for  process  improvement 


Measures  for  determining  the 
adequacy  of  the  MCCS  acqui¬ 
sition  management  process  are 
being  used  tor  process  im 
provemt.il 

Measures  for  determining  tin- 
adequacy  of  the  project  over¬ 
sight  process,  interfaces  with 
organizations  external  to  the 
program  office,  and  staff  train¬ 
ing  are  being  used  tor  process 
improvement. 


Measures  for  determining  the 
adequacy  of  the  contractor 
management  process  are  be¬ 
ing  used  for  process  improve¬ 
ment. 


Measures  for  determining  the 
adequacy  of  the  tr^ning  pro¬ 
gram  are  being  used  for  pro¬ 
cess  improvement. 


Measures  for  determining  the 
adequacy  of  the  CM  and  DM 
processes  are  being  used  for 
process  improvement. 


The  measures  for  determining 
the  adequacy  of  the  planning 
and  conduct  ot  the  T&E  effort 
are  being  used  for  process  im¬ 
provement. 

Measures  for  determing  the 
adequacy  of  the  risk  manage¬ 
ment  process  are  being  used 
for  process  improvement. 


Measures  tor  determining  the 
adequacy  of  the  SQA  process 
are  established.  Corrective 
measures  are  implemented 
where  necessary. 


Measures  for  determining  the 
adequacy  of  the  SQA  process 
are  being  used  for  process  im¬ 
provement. 


Measures  for  determining  the 
adequacy  of  the  definition  of 
supportability  requirements  and 
their  implementation  are  estab¬ 
lished.  Corrective  measures 
are  implemented  where  neces¬ 
sary. 


Measures  for  determining  the 
adequacy  of  the  definition  of 
supportability  requirements  and 
their  implementation  are  being 
used  for  process  improvement. 
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In  structuring  the  SAM^  the  fol¬ 
lowing  approach  was  taken:  utilize 
the  SEI  concept  of  five  levels  of  matu¬ 
rity,  and  use  the  approach  taken  by 
Oaskalantonakis  et  al  in  defining  a 
maturation  process  for  the  constitu¬ 
ent  themes.  In  defining  the  MCCS  key 
acquisition  process  areas,  the  key  pro¬ 
cesses  would  be  treated  as  the  themes 
were.  A  set  of  KPAs  would  be  defined, 
along  with  a  set  of  characteristics  that 
described  them  at  each  level  of  the 
maturity  model.  These  were  used  to 
help  define  the  key  practices  subordi¬ 
nate  to  the  KPAs.  This  approach  also 
becomes  a  building-block  model,  in 
that  the  practices  associated  with  each 
level  of  the  KPA  would  have  to  be 
implemented  by  the  organization  in 
order  for  it  to  be  considered  as  func¬ 
tioning  at  that  level.  Figure  1  illus¬ 
trates  this  hierarchy. 

Key  Process  Area  Structure 

The  literature'  on  the  revised  CMM 
was  used  as  a  reference  point  for 
defining  a  KPA  structure.  It  contains 
far  more  detail  than  does  the  litera¬ 
ture  on  the  original  version;  therefore, 
it  is  more  useful  for  this  purpose.  In 
the  description  of  the  original  version 
of  the  model,'  KPAs  are  hinted  at  but 
not  specifically  identified.  In  the  revi¬ 
sion  to  the  model,  a  hierarchy  of  ma¬ 
turity  levels,  KPAs,  key  practices  and 
key  indicators  has  been  established 
and  elaborated  upon.  The  maturity 
level  indicates  process  capability  and 
contains  key  processes  (or  KPAs) 
which  achieve  goals  for  each  of  the 
levels.  The  KPAs  contain  key  prac¬ 
tices  which  describe  implementation 
or  institutionalization  activities.  Key 
practices  specify  key  indicators  which 
spawn  candidate  questions  for  the 
questionnaire  used  in  the  assessment 
process  to  ascertain  the  capability 
level  at  which  the  organization  is  func¬ 
tioning. 

In  the  structure  established  for 
SAM\  the  definitions  of  the  levels  are 
the  same  as  for  the  SEI  model,  but 
their  characteristics  reflect  the  con¬ 
cerns  of  MCCS  acquisition,  rather  than 
software  development  processes.  The 


definitions  and  characteristics  of  the 
levels  are  described  in  Table  1.  In  this 
model,  organizations  may  be  at  one 
level  with  respect  to  one  key  process 
area,  but  at  a  different  level  with  re¬ 
spect  to  another.  In  this  regard,  the 
model  recognizes  that  organizations 
tend  to  mature  differentially.  For  ex¬ 
ample,  an  acquisition  organization 
may  be  better  equipped  to  exercise 
control  over  the  program’s  contrac¬ 
tors,  in  one  instance,  than  their  capa¬ 
bility  to  perform  configuration  man¬ 
agement  or  quality  assurance.  The 
levels  are  also  cumulative.  For  an 
organization  to  be  at  Level  4  in  any 
one  KPA,  for  instance,  all  the  key 
practices  identified  for  that  KPA  at 
Levels  2  and  3,  as  well  as  those  for 
Level  4,  must  be  in  place  and  in  force. 

In  drafting  this  initial  version  of 
SAM',  10  KPAs  have  been  defined. 
They  are: 

—  Requirements  Management 

—  MCCS  Acquisition  Management 

—  Software  Technical  Management 

—  Software  Project  Management 

—  Supportability 

—  Test  and  Evaluation 

—  Configuration  Management/Data 
Management 

—  Quality  Assurance 

—  Risk  Management 

—  Training. 

A  set  of  definitions  for  these  KPAs 
was  established  to  delineate  clearly 
what  kinds  of  activities  were  sub¬ 
sumed  under  them.  These  definitions 
are  presented  at  the  end  of  this  article. 
For  each  of  these  KPAs,  characteris¬ 
tics  were  defined  at  each  of  the  five 
levels  of  the  maturity  model.  Figure  2 
illustrates  the  structure.  Table  2  pro¬ 
vides  the  detailed  descriptions  of  the 
characteristics. 

The  key  practices  explicitly  define 
the  kinds  of  activities  that  must  be 
performed  at  each  level  for  the  key 
processes  for  the  organization  to  be 
considered  as  operating  at  that  level. 
They  identify  all  subjects  of  interest 
within  the  KPA  for  that  level,  and  are 


high-level  representations  of  those 
subjects.  For  instance,  at  Level  3,  for 
Configuration  ManagementyOata 
Management,  there  is  a  key  practice 
requiring  a  written  policy  or  standard 
that  defines  the  scope  of  CM  activities 
to  be  performed.  It  is  at  the  next  tier  of 
the  model;  i.e.,  the  key  indicators  for 
this  key  practice  (refer  to  Figure  1), 
that  the  specifics  of  what  is  to  be 
included  are  defined.  At  that  level  of 
detail,  the  issues  of  procedures  for 
configuration  identification,  change 
control,  baselines,  status  accounting, 
etc.,  are  addressed.  The  key  indica¬ 
tors  are  the  detailed  designation  of 
what  constitutes  the  fulfillment  of  the 
key  practice.  Because  they  are  so  de¬ 
tailed,  they  serve  as  the  basis  for  de¬ 
veloping  questions  to  include  in  a 
questionnaire  to  give  to  program  of¬ 
fice  key  personnel  as  part  of  an  as¬ 
sessment  process. 

Use  of  the  Model 

The  model  will  be  detailed  down  to 
the  level  of  the  definition  of  the  key 
indicators  for  each  key  process  area 
at  each  level  of  the  maturity  model. 
From  the  key  indicators,  an  assess¬ 
ment  questionnaire  will  be  developed. 

The  model  should  become  the  ba¬ 
sis  for  performing  assessments  of  ac¬ 
quisition  organizations  within  the 
DoD.  An  assessment  process,  analo¬ 
gous  to  the  SETs  software  process 
assessment,  will  be  developed.  It  will 
include  using  questionnaires  and  in¬ 
terviews  to  determine  the  level  at 
which  the  organization  is  functioning 
for  each  KPA.  The  primary  goal  of  the 
assessment  will  be  to  determine  what 
actions  are  necessary  to  improve  the 
functioning  level  of  the  organization 
with  regard  to  its  acquisition  prac¬ 
tices.  The  intent  is  to  reduce  risk  in 
MCCS  acquisition  and  obtain  better 
visibility  into  the  development  and 
maintenance  processes  to  preclude 
(at  best)  or  minimize  (at  worst)  the 
occurrence  of  unwanted  surprises. 

The  assessment  process  results  will 
be  portrayed  in  a  Kiviat  Diagram  which 
shows  the  maturity  level  for  each  KPA. 
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Requirements  Management 
5r 

Training  I  Acquisition  Management 


\  :  / 


Risk  Management 


Quality  Assurance 


ConflguraUon  Management/Data 
Management 


Software  Technical  Management 


Software  Project  Management 


Supportability 


Test  and  Evaluation 


Figure  3  illustrates  what  an  assess¬ 
ment  outcome  could  look  like.  Note 
that  each  KPA  is  plotted  on  the  Kiviat 
diagram  according  to  its  maturity  level 
as  ascertained  by  the  assessment  pro¬ 
cess.  This  provides  a  great  deal  of 
useful  intelligence. 

The  hypothetical  example  provided 
in  Figure  3  notes  the  following  find¬ 
ings; 


Key  Process  Area  Level 

Requirements  Mgmt  2 

Acquisition  Mgmt  3 

Software  Technical  Mgmt  2 

Software  Project  Mgmt  1 

Supportability  2 

Test  and  Evaluation  3 

Config  Mgmt/Data  Mgmt  1 

Quality  Assurance  1 

Risk  Management  1 

Training  3 


In  some  areas,  this  program  office 
is  doing  well;  in  others,  quite  poorly. 
A  reasonable  strategy  for  improve¬ 
ment  for  this  program  office  would  be 
to  focus  on  bringing  the  Level  1  KPAs 
up  to  Level  2,  and  then  bringing  all  the 
Level  2  KPAs  up  to  Level  3.  This 
means  that  this  hypothetical  program 
office  should  concentrate  on  estab¬ 
lishing  the  key  practices  related  to 
exercising  oversight  of  activities  in 
the  program  office;  managing  inter¬ 
faces  with  external  organizations  such 
as  research  and  development  (R&D) 
laboratories,  software  support  activi¬ 


ties,  members  of  the  user  community, 
etc.;  exercising  good  configuration  and 
data  management  over  project  docu¬ 
mentation  produced  by  the  contrac¬ 
tor  or  the  program  office;  and  exercis¬ 
ing  good  quality  assurance  practices 
over  the  project’s  development  prod¬ 
ucts. 

If  the  assessment  was  performed 
on  a  number  of  program  offices  that 
report  to  one  program  executive,  the 
information  would  be  presented  as  a 
composite  of  the  program  offices 
within  the  executive’s  organization. 
The  level  shown  for  each  KPA  would 
be  an  average  of  all  the  program  of¬ 
fices  for  that  KPA. 

In  general,  it  would  seem  that  the 
SEl  methodology  for  performing  the 
software  process  assessments  should 
be  followed  here.  This  methodology 
provides  for  anonymity  of  the  sources 
for  the  information,  and  the  findings 
reported  to  an  organization’s  man¬ 
agement  are  a  composite  of  all  sur¬ 
veyed  programs  in  that  organization. 
They  also  represent  a  consensus  of 
opinion  of  the  practitioners  within 
that  organization  —  those  supporting 
the  surveyed  programs,  and  those 
working  on  others.  The  guarantee  of 
anonymity  and  the  emphasis  on  con¬ 
sensus  prompts  cooperation  from  all 
the  assessment  participants.  If  an 
acquisition  assessment  were  per¬ 
formed  on  a  single  program  office,  or 
if  the  results  within  an  executive’s 


organization  were  reported  by  pro¬ 
gram  office,  anonymitN'  could  not  be 
guaranteed.  The  assessment  would 
appear  to  be  an  audit,  and  partici¬ 
pants  would  feel  threatened.  Such  an 
assessment  may  not  be  successful. 
Consequently,  the  same  principles 
applied  to  a  software  process  assess¬ 
ment  should  be  followed  in  the 
assessment  of  an  acquisition  organi¬ 
zation. 


Conclusions 

The  approach  outlined  here  holds 
great  promise  for  properly  character¬ 
izing  an  acquisition  organization’s 
capability  to  manage  MCCS  acquisi¬ 
tion.  It  combines  proven  concepts 
from  the  SEl  Capability  Maturity 
Model  together  with  innovative  con¬ 
cepts  suggested  by  Daskalantonakis 
et  al.  A  first  cut  at  developing  key 
practices  for  the  key  process  areas 
indicates  that  the  acquisition  matu¬ 
rity  model  is  viable.  Refinement  of  the 
key  practices  is  in  progress.  Verifica¬ 
tion  of  the  key  practices  is  the  next 
logical  step  after  completion  of  the 
key  indicator  definitions.  This  latter 
activity  is  utilizing  a  number  of  source 
documents  to  ensure  the  key  prac¬ 
tices  reflect  all  mandated  actions,  as 
well  as  those  that  a  consensus  indi¬ 
cates  should  be  in  place  as  good 
practice. 
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KEY  PROCESS  AREA  DEFINITIONS 


1.  Requirements  Management.  How  well  the  pro¬ 
gram  office  manages  the  process  of  defining,  baselining 
and  controlling  changes  to  the  MCCS  requirements 
that  will  eventually  be  imposed  on  the  development 
contractor  or  the  software  support  activity.  It  also 
relates  to  assuring  complete  traceability  backward 
and  forward  from  the  original  statement  of  overall 
system  requirements  through  changes  to  the  software 
requirements  definitions  that  occur  during  Post-De¬ 
ployment  Software  Support  (sofnvare  maintenance). 
It  relates,  as  well,  to  ensuring  the  participation  of  all 
affected  parties  in  the  definition  process. 

2.  MCCS  Acquisition  Management.  How  well  the 
program  office  manages  the  process  of  developing  the 
acquisition  management  requirements  prescribed  by 
the  DoD  and  Service  directives  and  instructions,  and 
in  developing  content  for  the  MCCS  portions  of  the 
solicitation  for  the  various  phases  of  the  system  life 
cycle.  In  particular,  this  relates  to  the  supporting 
MCCS  information  required  as  a  consequence  of  the 
provisions  of  DoD  Directive  5000. 1  and  DoD  Instruc¬ 
tion  5000.2,  and  implementing  regulations/instruc¬ 
tions. 

3.  Software  Project  Management.  How  well  pro¬ 
gram  management  manages  the  activities  of  the  pro¬ 
gram  office  with  regard  to  MCCS  acquisition,  such  as 
budgeting,  scheduling,  estimation  of  software  size  and 
development  costs,  staffing,  training,  etc.  It  also  re¬ 
lates  to  program  office  interfaces  with  other  affected 
DoD  organizations  supporting  the  management  of  the 
acquisition,  for  example,  software  support  activities, 
R&D  laboratories,  etc.  Also  included  is  the  program 
office’s  understanding  of  the  necessity  for  their  per¬ 
sonnel  to  acquire  the  skills  necessary  to  effectively 
manage  and  monitor  MCCS  development  and  mainte¬ 
nance.  Accordingly,  it  addresses  the  planning  and 
execution  of  training  programs  to  acquire  the  requisite 
skills. 

4.  Software  Technical  Management.  How  well  the 
PM  manages  the  technical  aspects  of  the  contract(s) 
let  to  the  prime  contractorfs)  or  to  organic  software 
development  organizations  for  the  MCCS.  It  also 
relates  to  the  definition  of  the  life-cycle  model  to  be 
implemented,  language  deviations  or  waivers  to  be 
allowed  (if  at  all),  provisions  for  software  safety,  secu¬ 
rity,  etc. 

5.  Quality  Assurance.  Relates  to  the  performance  in 
the  program  office  of  Software  Quality  Assurance  on 


the  contractorfs)  products  and  activities,  as  well  as  to 
activities  performed  by  the  program  office  in  carrying 
out  configuration  control,  test,  or  similar  activities  on 
delivered  products. 

6.  Configuration  Management/Data  Manage¬ 
ment.  Relates  to  the  performance  in  the  program  office 
of  soft\..;.e  configuration  management  (SCM)  and 
data  management  (DM)  on  products  delivered  from 
the  contractor(s).  It  also  relates  to  the  coordination  of 
SCM  and  DM  requirements  with  the  affected  software 
support  organization(s)  and  other  field  organizations 
and  users,  to  ensure  compatibility. 

7.  Suppoitability.  Relates  to  the  ability  of  the  pro¬ 
gram  office  to  address  the  supportability  issues  unique 
to  MCCS,  particularly,  specification  of  quality  goals 
for  the  MCCS  and  the  reliability  of  the  military  system 
in  which  it  is  embedded,  definition  of  the  support 
system  and  support  levels  required  to  field  the  system, 
maintainability  of  the  software  and  the  computer 
system  in  which  it  is  embedded,  training  for  both  the 
users  and  the  personnel  maintaining  the  system  at  the 
software  support  activities,  etc. 

8.  Test  and  Evaluation.  Relates  to  the  ability  of  the 
program  office  to  plan,  monitor  and  participate  in  the 
MCCS  test  and  evaluation  (T&E).  Specifically,  the 
goal  is  to  develop  an  integrated  approach  to  T&E 
ensuring  that: 

—  The  contractor’s  development  and  acceptance  test 
efforts  mesh  with  the  government’s  operational  T&E 
efforts 

—  Both  programs  complement  each  other  in  validat¬ 
ing  that  the  fielded  software  meets  operational  re¬ 
quirements. 

9.  Risk  Management.  Relates  to  the  ability  of  the 
program  office  to  identify,  analyze,  control  and  miti¬ 
gate  technology;  development  organization  capabil¬ 
ity,  performance,  schedule,  cost  and  supportability 
risks  associated  with  MCCS  development  and  mainte- 


10.  Training.  Oriented  toward  the  understanding  of 
the  program  office  of  the  necessity  for  their  personnel 
to  acquire  the  skills  necessary  to  manage  and  monitor 
MCCS  development  and  maintenance  effectively.  It 
addresses  the  planning  and  execution  of  training  pro¬ 
grams  to  acquire  the  requisite  skills. 


